Untitled Document

From xen-arm-bounces@lists.xen.org Thu May 03 14:37:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 1SPx9S-0000JF-48; Thu, 03 May 2012 14:37:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPx9Q-0000Iy-De for xen-arm@lists.xen.org; Thu, 03 May 2012 14:37:00 +0000 Received: from [85.158.138.51:56199] by server-1.bemta-3.messagelabs.com id 37/04-11491-B0892AF4; Thu, 03 May 2012 14:36:59 +0000 X-Env-Sender: maryjoy883@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336055817!25110580!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-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28369 invoked from network); 3 May 2012 14:36:58 -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; 3 May 2012 14:36:58 -0000 Received: by yenr5 with SMTP id r5so2237009yen.32 for ; Thu, 03 May 2012 07:36:57 -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=Fg8Yqz0bUSig48+o7FpM3l9HsrDAi0tKmGVFh5VSunY=; b=e97UVTG1Vpc+FjSTDG5T05vrS5EUTxolMZeyeKx56k32J8LOaG8GH4nW+xX2j5S+cz QNlhJ4HJcoV5gIuFZrrKcdUZ7Fk6XEwTIew6jll/t1tHKAMXRh6OdYyPXVH6tfaVb/+G Xms6/VQSKPJ1ei4hhQchX01nnRGvQmFjwtax+PdV8y8aWK+nIdfNk7BKkC62oQ65IXRb S11GbYluPriaEbpNbHXnly98I3iDQxORQ22qli/hxc157MzCRfaKwM8teMIS81YSw71g hn+mIiKSUa2AuSynq/H6hXgZwasFHETaMqY16c5WNQmvR3WR6TN+6WMma+w5M5zNngEo opEA== Received: by 10.50.187.231 with SMTP id fv7mr841488igc.51.1336055817291; Thu, 03 May 2012 07:36:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.95.200 with HTTP; Thu, 3 May 2012 07:36:37 -0700 (PDT) From: mabel mary joy Date: Thu, 3 May 2012 16:36:37 +0200 Message-ID: To: xen-arm@lists.xen.org Subject: [XenARM] Xen on Qemu X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0392199339414000727==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============0392199339414000727== Content-Type: multipart/alternative; boundary=14dae9340fcf63c57204bf22bcea --14dae9340fcf63c57204bf22bcea Content-Type: text/plain; charset=ISO-8859-1 Hi Is it possible to run this Xen on ARM on an emulated platform like Qemu? Do you have any such released version for Qemu? -- Regards Mary --14dae9340fcf63c57204bf22bcea Content-Type: text/html; charset=ISO-8859-1 Hi

Is it possible to run this Xen on ARM on an emulated platform like Qemu?
Do you have any such released version for Qemu?

--
Regards
Mary
--14dae9340fcf63c57204bf22bcea-- --===============0392199339414000727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============0392199339414000727==-- From xen-arm-bounces@lists.xen.org Thu May 03 14:37:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 1SPx9S-0000JF-48; Thu, 03 May 2012 14:37:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPx9Q-0000Iy-De for xen-arm@lists.xen.org; Thu, 03 May 2012 14:37:00 +0000 Received: from [85.158.138.51:56199] by server-1.bemta-3.messagelabs.com id 37/04-11491-B0892AF4; Thu, 03 May 2012 14:36:59 +0000 X-Env-Sender: maryjoy883@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336055817!25110580!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-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28369 invoked from network); 3 May 2012 14:36:58 -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; 3 May 2012 14:36:58 -0000 Received: by yenr5 with SMTP id r5so2237009yen.32 for ; Thu, 03 May 2012 07:36:57 -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=Fg8Yqz0bUSig48+o7FpM3l9HsrDAi0tKmGVFh5VSunY=; b=e97UVTG1Vpc+FjSTDG5T05vrS5EUTxolMZeyeKx56k32J8LOaG8GH4nW+xX2j5S+cz QNlhJ4HJcoV5gIuFZrrKcdUZ7Fk6XEwTIew6jll/t1tHKAMXRh6OdYyPXVH6tfaVb/+G Xms6/VQSKPJ1ei4hhQchX01nnRGvQmFjwtax+PdV8y8aWK+nIdfNk7BKkC62oQ65IXRb S11GbYluPriaEbpNbHXnly98I3iDQxORQ22qli/hxc157MzCRfaKwM8teMIS81YSw71g hn+mIiKSUa2AuSynq/H6hXgZwasFHETaMqY16c5WNQmvR3WR6TN+6WMma+w5M5zNngEo opEA== Received: by 10.50.187.231 with SMTP id fv7mr841488igc.51.1336055817291; Thu, 03 May 2012 07:36:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.95.200 with HTTP; Thu, 3 May 2012 07:36:37 -0700 (PDT) From: mabel mary joy Date: Thu, 3 May 2012 16:36:37 +0200 Message-ID: To: xen-arm@lists.xen.org Subject: [XenARM] Xen on Qemu X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0392199339414000727==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============0392199339414000727== Content-Type: multipart/alternative; boundary=14dae9340fcf63c57204bf22bcea --14dae9340fcf63c57204bf22bcea Content-Type: text/plain; charset=ISO-8859-1 Hi Is it possible to run this Xen on ARM on an emulated platform like Qemu? Do you have any such released version for Qemu? -- Regards Mary --14dae9340fcf63c57204bf22bcea Content-Type: text/html; charset=ISO-8859-1 Hi

Is it possible to run this Xen on ARM on an emulated platform like Qemu?
Do you have any such released version for Qemu?

--
Regards
Mary
--14dae9340fcf63c57204bf22bcea-- --===============0392199339414000727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============0392199339414000727==-- From xen-arm-bounces@lists.xen.org Thu May 03 16:30:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16:30: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 1SPyvY-00047m-Vl; Thu, 03 May 2012 16:30:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyvX-00047L-Et for xen-arm@lists.xen.org; Thu, 03 May 2012 16:30:47 +0000 Received: from [85.158.143.35:33433] by server-2.bemta-4.messagelabs.com id C5/FE-17550-6B2B2AF4; Thu, 03 May 2012 16:30:46 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336062645!14921320!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30537 invoked from network); 3 May 2012 16:30:45 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 16:30:45 -0000 Received: by eekc4 with SMTP id c4so95309eek.32 for ; Thu, 03 May 2012 09:30:45 -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=ue9NJDg+1BM0CPGjQm3nShJ1RX89uNTmlIklzjpBq8k=; b=V28QjH2OW/4e1jV4Rr6Dj/JWxfaUK1ysRbFNjCccDpL8IQzEZjvJXZOXJDHsVdXUXP vbk6dcVd4pTHa/73B7QU/kVrxwsP2nnYDTnTRo+TfVfq6hEAEQETt1cCAXG3Hjbdgp83 acz+BZoRQkPu87I+ocyBPWyURMEVWMisUd5e8clR80l6QQ75blmzP0AkKorqrlTTPBPC cZUw3FjrEh3u7CJWT6p5Dgy8faZi2l63AOcufLCW3mAZbD7OIg6y36OkohWNYIYCC4Sh RxutUrBWByvc8uAFG/Eeg0MpOCGBH5pO2wm/SdunlyUTER7LMgrFr8dvtC51myv3+FiB +Whg== Received: by 10.14.99.137 with SMTP id x9mr606262eef.15.1336062645127; Thu, 03 May 2012 09:30:45 -0700 (PDT) Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55]) by mx.google.com with ESMTPS id n52sm20834382eef.6.2012.05.03.09.30.42 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 09:30:43 -0700 (PDT) Message-ID: <4FA2B2B1.3040901@xen.org> Date: Thu, 03 May 2012 17:30:41 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen-devel@lists.xen.org, xen-api@lists.xen.org, xen-arm@lists.xen.org Subject: [XenARM] [Proposal] Minor additions and clarification to Xen Project Governance X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Dear Developers, we have had the original Xen project governance document (see http://xen.org/projects/governance.html ) in effect now since July last year. The last minor review was in October 2011. Since then I had feedback on two items: a) Our governance does not specify how friction in the community is resolved. The role definitions cover the concept of Committers and Project leads acting as Referees, without being specific. In essence, the proposal reflects what happens informally in practice today and has happened in the past. b) There also was a bug in the definition of Project Lead: "Xen.org projects are managed by a Project Lead, who also is a maintainer" should be "..., who also is a committer". I clarified this and added a sentence that a project lead can also act as referee (which was implied before as a project lead is a committer). Please find a proposal for a new revision of the process at http://xen.org/projects/governance_v1_2.html which fixes these two issues. Changes are marked in italics and are in sections "Conflict Resolution" and "Project Lead". Timetable: 1) Open review with feedback until 11th May (a bit more than a week from today) 2) Lars to incorporate any feedback and publish a revision. 3) Lars to set up a private poll via a form, the week of May 14th which will be open for a week. Community members that can vote are maintainers (including committers and maintainers)of any mature project in Xen (aka Xen and XCP). Best Regards Lars _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Thu May 03 16:30:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16:30: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 1SPyvY-00047m-Vl; Thu, 03 May 2012 16:30:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyvX-00047L-Et for xen-arm@lists.xen.org; Thu, 03 May 2012 16:30:47 +0000 Received: from [85.158.143.35:33433] by server-2.bemta-4.messagelabs.com id C5/FE-17550-6B2B2AF4; Thu, 03 May 2012 16:30:46 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336062645!14921320!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30537 invoked from network); 3 May 2012 16:30:45 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 16:30:45 -0000 Received: by eekc4 with SMTP id c4so95309eek.32 for ; Thu, 03 May 2012 09:30:45 -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=ue9NJDg+1BM0CPGjQm3nShJ1RX89uNTmlIklzjpBq8k=; b=V28QjH2OW/4e1jV4Rr6Dj/JWxfaUK1ysRbFNjCccDpL8IQzEZjvJXZOXJDHsVdXUXP vbk6dcVd4pTHa/73B7QU/kVrxwsP2nnYDTnTRo+TfVfq6hEAEQETt1cCAXG3Hjbdgp83 acz+BZoRQkPu87I+ocyBPWyURMEVWMisUd5e8clR80l6QQ75blmzP0AkKorqrlTTPBPC cZUw3FjrEh3u7CJWT6p5Dgy8faZi2l63AOcufLCW3mAZbD7OIg6y36OkohWNYIYCC4Sh RxutUrBWByvc8uAFG/Eeg0MpOCGBH5pO2wm/SdunlyUTER7LMgrFr8dvtC51myv3+FiB +Whg== Received: by 10.14.99.137 with SMTP id x9mr606262eef.15.1336062645127; Thu, 03 May 2012 09:30:45 -0700 (PDT) Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55]) by mx.google.com with ESMTPS id n52sm20834382eef.6.2012.05.03.09.30.42 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 09:30:43 -0700 (PDT) Message-ID: <4FA2B2B1.3040901@xen.org> Date: Thu, 03 May 2012 17:30:41 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen-devel@lists.xen.org, xen-api@lists.xen.org, xen-arm@lists.xen.org Subject: [XenARM] [Proposal] Minor additions and clarification to Xen Project Governance X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Dear Developers, we have had the original Xen project governance document (see http://xen.org/projects/governance.html ) in effect now since July last year. The last minor review was in October 2011. Since then I had feedback on two items: a) Our governance does not specify how friction in the community is resolved. The role definitions cover the concept of Committers and Project leads acting as Referees, without being specific. In essence, the proposal reflects what happens informally in practice today and has happened in the past. b) There also was a bug in the definition of Project Lead: "Xen.org projects are managed by a Project Lead, who also is a maintainer" should be "..., who also is a committer". I clarified this and added a sentence that a project lead can also act as referee (which was implied before as a project lead is a committer). Please find a proposal for a new revision of the process at http://xen.org/projects/governance_v1_2.html which fixes these two issues. Changes are marked in italics and are in sections "Conflict Resolution" and "Project Lead". Timetable: 1) Open review with feedback until 11th May (a bit more than a week from today) 2) Lars to incorporate any feedback and publish a revision. 3) Lars to set up a private poll via a form, the week of May 14th which will be open for a week. Community members that can vote are maintainers (including committers and maintainers)of any mature project in Xen (aka Xen and XCP). Best Regards Lars _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Fri May 04 05:34:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 05:34: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 1SQB9g-000898-Q6; Fri, 04 May 2012 05:34:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQB9f-00088z-1y for xen-arm@lists.xen.org; Fri, 04 May 2012 05:34:11 +0000 Received: from [193.109.254.147:27561] by server-7.bemta-14.messagelabs.com id E2/7C-01627-25A63AF4; Fri, 04 May 2012 05:34:10 +0000 X-Env-Sender: post4pavan@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336109648!7595486!1 X-Originating-IP: [209.85.161.173] 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-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19291 invoked from network); 4 May 2012 05:34:09 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 05:34:09 -0000 Received: by ggno5 with SMTP id o5so276132ggn.32 for ; Thu, 03 May 2012 22:34: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=A9cB491Qch6y4w2xV4TlyG4RVdgqbUYU3DE9Qopm3PY=; b=DffqwMqSR/HFoWgEeSfiZ2rmrOewtkKhHJMus+dUfNsMATkwICRj88RAmiRKl2jyfl U1UrTJ3xhf1hSvMtHgoaCv+aTKPHM5bvjc8KCKScVyEpm0L1ZUcS6X169lKJJ+B0Mcg8 powyCOSR74NJeKBaIp6v4MqUXz9f8kQ7Dj/5n4faShChd4jYKpvM882qqakgFOZB7cFh YUyaER0NsuNuCFNTrGbrDczURAqc4CqHivXhsIZda3WGIWdjZDKt3/zotR42ofLJ7PTg GP/4o40SKuc6wW9BiZ+lHEOctd6Ser4f1gzlZWTXkfID7E21N47M0Nc34vuKf6VFI8SS kKSg== MIME-Version: 1.0 Received: by 10.50.169.3 with SMTP id aa3mr2204333igc.28.1336109647811; Thu, 03 May 2012 22:34:07 -0700 (PDT) Received: by 10.42.241.131 with HTTP; Thu, 3 May 2012 22:34:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 May 2012 11:04:07 +0530 Message-ID: From: Krishna Pavan To: mabel mary joy Cc: xen-arm@lists.xen.org Subject: Re: [XenARM] Xen on Qemu X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4961377256003718222==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============4961377256003718222== Content-Type: multipart/alternative; boundary=e89a8f234361f0560d04bf2f442c --e89a8f234361f0560d04bf2f442c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ya, this is the link. http://downloads.xen.org/Wiki/XenARM/xen-arm-opensource-20081210.tar.bz2for xen-ARM, http://downloads.xen.org/Wiki/XenARM/qemu-xen_arm-081120.tar.bz2 for Android Goldfish on QEMU. I have not been successful with that. Hope you could. Please Kindly inform me your progress. --=20 =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D --e89a8f234361f0560d04bf2f442c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ya, this is the link.

h= ttp://downloads.xen.org/Wiki/XenARM/xen-arm-opensource-20081210.tar.bz2= for xen-ARM,

http://downloads.xen.org/Wiki/XenARM/qemu-xen_arm-081120.tar.bz2 = for Android Goldfish on QEMU.

I have not been successful with that.<= br>
Hope you could. Please Kindly inform me your progress.

--

= =E2=9C=89 Regards :: Krishna Pavan<= /font> =E2=9C=8D=

--e89a8f234361f0560d04bf2f442c-- --===============4961377256003718222== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============4961377256003718222==-- From xen-arm-bounces@lists.xen.org Sat May 05 08:39:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 08: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 1SQaWb-0003Rt-MB; Sat, 05 May 2012 08:39:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQaWa-0003Rj-Q1 for xen-arm@lists.xensource.com; Sat, 05 May 2012 08:39:33 +0000 Received: from [85.158.143.99:58556] by server-3.bemta-4.messagelabs.com id 42/1C-05853-447E4AF4; Sat, 05 May 2012 08:39:32 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-2.tower-216.messagelabs.com!1336207169!21287697!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG, HTML_00_10,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18691 invoked from network); 5 May 2012 08:39: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; 5 May 2012 08:39:31 -0000 Received: by vbbfq11 with SMTP id fq11so3354133vbb.30 for ; Sat, 05 May 2012 01:39:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=aVvFUQKqy83AAlIr8UOls1Pr3Fu3aa5cJ/kfegOSqak=; b=H+mqcFBk/kI/t1owYQreygZ3eGGUWwIQ6FDMvUz3CxHHaGbCf9FiMbtivLby3gJSfm 4GhhDxEDWnR4ujapsJq4S1hYSjkrlTK6gZzqT26nAUqolVIlZkfU89YHelOuvFtDsAR9 qUFLOxHYHPTnHl7TX3J6GYT3JYKVJyE3VpK/vCJrxFLP+Bh140uZt4Q4mS3pWzJk8yyf QUk077cKZEIGhb7EmdESE+R0eO5Fz1ohttGC5ZzSpAOse8votekuki2cfvUnzDmVaoHs RyjXJ7KhZ7gHY/rXdc+uwh0Wm86KMm3kS3e6weIAf9vCykqiy7ZfYmBHeiqnwTwuwRRA iqUQ== MIME-Version: 1.0 Received: by 10.52.66.40 with SMTP id c8mr3649528vdt.63.1336207169400; Sat, 05 May 2012 01:39:29 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 01:39:29 -0700 (PDT) X-Originating-IP: [14.97.5.37] Date: Sat, 5 May 2012 14:09:29 +0530 Message-ID: From: Anup Patel To: android-virt@lists.cs.columbia.edu, xen-arm@lists.xensource.com, xen-arm@lists.xen.org, Xvisor Devel X-Gm-Message-State: ALoCoQmkgIEq2IX9BnEN79iGo8UnBrZVIWiT4QI2PKroDMx2JQFQ6dH5Ajbs1lqLP49dwl524gnp Subject: [XenARM] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1093705273732592162==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============1093705273732592162== Content-Type: multipart/alternative; boundary=20cf307cff84adaeff04bf45f978 --20cf307cff84adaeff04bf45f978 Content-Type: text/plain; charset=ISO-8859-1 This announcement is to show an apple to apple performance comparison between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. Both hypervisors leverage the ARMv7a Virtualization Extensions for accelerated performance in CPU virtualization, but both of them are fundamentally different from each other. Xvisor ARM is a complete monolithic hypervisor having one common software for host hardware access, CPU virtualization, and guest IO emulation. The KVM ARM hypervisor is somewhere in between monolithic and microkernelized hypervisors. In KVM ARM the host hardware access + CPU virtualization is one piece of software (i.e. Linux+KVM driver) wherease guest IO emulation is another piece of software (i.e. QEMU). The binary size of Xvisor ARM for VExpress-A15 is 294 KB whereas that of Linux KVM ARM is 2.1 MB. In addition to this Xvisor ARM for VExpress-A15 runs with a modest memory usage of 8 MB (most of which is still free even when Linux guest is running). To have an apple to apple comparison we did few test on Realview-PB-A8 guest emulated by both these hypervisors, such as: Test1: Time taken to boot linux kernel Test2: Time taken to compute md5sum of a 1560 KB file Test3: DMIPS obtained by running dhrystone Native Linux for VExpress-A15 Test1: 15 secs (Boot Time) Test2: 38 secs (md5sum on 1560 KB) Test3: 153 DMIPS (or 270255 dhrystones per second) Realview-PB-A8 Linux Guest on Xvisor ARM for VExpress-A15 Test1: 10 secs (Boot Time) Test2: 40 secs (md5sum on 1560 KB) Test3: 151 DMIPS (or 265486 dhrystones per second) Realview-PB-A8 Linux Guest on KVM ARM for VExpress-A15 Test1: 30 secs (Boot Time) Test2: 41 secs (md5sum on 1560 KB) Test3: 141 DMIPS (or 247737 dhrystones per second) (Note: we have used same linux images for running as guest on Xvisor ARM and KVM ARM) The above numbers clearly show that the monolithic nature of Xvisor ARM gives it a great performance advantage over KVM ARM even though both use hardware assisted CPU virtualization. Xvisor ARM is able to boot multiple unmodified linux even without hardware virtualization support but KVM ARM needs ARMv7a virtualization extensions. On real hardware specifically BeagleBoard-xM (OMAP3 @ 600 MHz) we get near native CPU performance without virtualization extensions (i.e. Native Linux 3.0.4 gives 1120 DMIPS whereas Linux 3.0.4 running as guest on Xvisor ARM gives 960 DMIPS) --20cf307cff84adaeff04bf45f978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This announcement is to show an apple to apple performance comparison betwe= en
Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. Both hyper= visors
leverage the ARMv7a Virtualization Extensions for accelerated per= formance
in CPU virtualization, but both of them are fundamentally different fromeach other.

Xvisor ARM is a complete monolithic hypervisor having o= ne common software
for host hardware access, CPU virtualization, and gue= st IO emulation. The
KVM ARM hypervisor is somewhere in between monolithic and microkernelizedhypervisors. In KVM ARM the host=A0 hardware access + CPU virtualization = is
one piece of software (i.e. Linux+KVM driver) wherease guest IO emula= tion
is another piece of software (i.e. QEMU).

The binary size of Xvisor = ARM for VExpress-A15 is 294 KB whereas that of
Linux KVM ARM is 2.1 MB. = In addition to this Xvisor ARM for VExpress-A15
runs with a modest memor= y usage of 8 MB (most of which is still free even
when Linux guest is running).

To have an apple to apple comparison w= e did few test on Realview-PB-A8 guest
emulated by both these hypervisor= s, such as:
Test1: Time taken to boot linux kernel
Test2: Time taken = to compute md5sum of a 1560 KB file
Test3: DMIPS obtained by running dhrystone

Native Linux for VExpress= -A15
Test1: 15 secs (Boot Time)
Test2: 38 secs (md5sum on 1560 KB)Test3: 153 DMIPS (or 270255 dhrystones per second)

Realview-PB-A8 L= inux Guest on Xvisor ARM for VExpress-A15
Test1: 10 secs (Boot Time)
Test2: 40 secs (md5sum on 1560 KB)
Test3: = 151 DMIPS (or 265486 dhrystones per second)

Realview-PB-A8 Linux Gue= st on KVM ARM for VExpress-A15
Test1: 30 secs (Boot Time)
Test2: 41 s= ecs (md5sum on 1560 KB)
Test3: 141 DMIPS (or 247737 dhrystones per second)

(Note: we have us= ed same linux images for running as guest on Xvisor ARM
and KVM ARM)
=
The above numbers clearly show that the monolithic nature of Xvisor ARM=
gives it a great performance advantage over KVM ARM even though both usehardware assisted CPU virtualization.

Xvisor ARM is able to boot mu= ltiple unmodified linux even without hardware
virtualization support but= KVM ARM needs ARMv7a virtualization extensions.

On real hardware specifically BeagleBoard-xM (OMAP3 @ 600 MHz) we get n= ear
native CPU performance without virtualization extensions (i.e. Nativ= e Linux
3.0.4 gives 1120 DMIPS whereas Linux 3.0.4 running as guest on X= visor ARM
gives 960 DMIPS)
--20cf307cff84adaeff04bf45f978-- --===============1093705273732592162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============1093705273732592162==-- From xen-arm-bounces@lists.xen.org Sat May 05 08:39:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 08: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 1SQaWb-0003Ry-P7; Sat, 05 May 2012 08: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 1SQaWa-0003Rk-Vg for xen-arm@lists.xen.org; Sat, 05 May 2012 08:39:33 +0000 Received: from [85.158.139.83:18551] by server-2.bemta-5.messagelabs.com id CC/08-17016-447E4AF4; Sat, 05 May 2012 08:39:32 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-16.tower-182.messagelabs.com!1336207169!19531849!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG, HTML_00_10,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5924 invoked from network); 5 May 2012 08:39:31 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vx0-f173.google.com) (209.85.220.173) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 08:39:31 -0000 Received: by vcbfl11 with SMTP id fl11so3230702vcb.32 for ; Sat, 05 May 2012 01:39:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=aVvFUQKqy83AAlIr8UOls1Pr3Fu3aa5cJ/kfegOSqak=; b=asbk5jbi4vg7d5uz0C3wquTKiRMRzd45Er7/oJtiV9fzBk9WiDgE020N6/fhJvBomy Rci8JasKzD4Xzk0sH5HCfgvO0KwUZSNWRCrx9QC2CHNWUl7ltAz+68b0lbdbTMRBrHJ4 huQFc3sMVPz6xmwrkM/lj8Ykjla2/dRrsxU7eYtaFS3zIktIfuxUgaaxkOHry2ynnyGT N+TZ+unjSLaYs7ETTKf0cvTpUMeWvmPeGVzbycvvFcH/H19uA81uD005lREUr947LqWw BKaJGaX/Kq5kQhT8QlYgeGEPlXKWZmFJOuCCYgTbDzDyj9wbCpl8Z8yz/yfYAcfVp5TZ 3Wbg== MIME-Version: 1.0 Received: by 10.52.66.40 with SMTP id c8mr3649528vdt.63.1336207169400; Sat, 05 May 2012 01:39:29 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 01:39:29 -0700 (PDT) X-Originating-IP: [14.97.5.37] Date: Sat, 5 May 2012 14:09:29 +0530 Message-ID: From: Anup Patel To: android-virt@lists.cs.columbia.edu, xen-arm@lists.xensource.com, xen-arm@lists.xen.org, Xvisor Devel X-Gm-Message-State: ALoCoQmz6k8ybDs+mc+989CP4nX+0R7EGMMLfLE4fFLl9URtDm+IPaAn2uDcsARrUIU3w8U3P5yu Subject: [XenARM] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8197519526125896745==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============8197519526125896745== Content-Type: multipart/alternative; boundary=20cf307cff84adaeff04bf45f978 --20cf307cff84adaeff04bf45f978 Content-Type: text/plain; charset=ISO-8859-1 This announcement is to show an apple to apple performance comparison between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. Both hypervisors leverage the ARMv7a Virtualization Extensions for accelerated performance in CPU virtualization, but both of them are fundamentally different from each other. Xvisor ARM is a complete monolithic hypervisor having one common software for host hardware access, CPU virtualization, and guest IO emulation. The KVM ARM hypervisor is somewhere in between monolithic and microkernelized hypervisors. In KVM ARM the host hardware access + CPU virtualization is one piece of software (i.e. Linux+KVM driver) wherease guest IO emulation is another piece of software (i.e. QEMU). The binary size of Xvisor ARM for VExpress-A15 is 294 KB whereas that of Linux KVM ARM is 2.1 MB. In addition to this Xvisor ARM for VExpress-A15 runs with a modest memory usage of 8 MB (most of which is still free even when Linux guest is running). To have an apple to apple comparison we did few test on Realview-PB-A8 guest emulated by both these hypervisors, such as: Test1: Time taken to boot linux kernel Test2: Time taken to compute md5sum of a 1560 KB file Test3: DMIPS obtained by running dhrystone Native Linux for VExpress-A15 Test1: 15 secs (Boot Time) Test2: 38 secs (md5sum on 1560 KB) Test3: 153 DMIPS (or 270255 dhrystones per second) Realview-PB-A8 Linux Guest on Xvisor ARM for VExpress-A15 Test1: 10 secs (Boot Time) Test2: 40 secs (md5sum on 1560 KB) Test3: 151 DMIPS (or 265486 dhrystones per second) Realview-PB-A8 Linux Guest on KVM ARM for VExpress-A15 Test1: 30 secs (Boot Time) Test2: 41 secs (md5sum on 1560 KB) Test3: 141 DMIPS (or 247737 dhrystones per second) (Note: we have used same linux images for running as guest on Xvisor ARM and KVM ARM) The above numbers clearly show that the monolithic nature of Xvisor ARM gives it a great performance advantage over KVM ARM even though both use hardware assisted CPU virtualization. Xvisor ARM is able to boot multiple unmodified linux even without hardware virtualization support but KVM ARM needs ARMv7a virtualization extensions. On real hardware specifically BeagleBoard-xM (OMAP3 @ 600 MHz) we get near native CPU performance without virtualization extensions (i.e. Native Linux 3.0.4 gives 1120 DMIPS whereas Linux 3.0.4 running as guest on Xvisor ARM gives 960 DMIPS) --20cf307cff84adaeff04bf45f978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This announcement is to show an apple to apple performance comparison betwe= en
Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. Both hyper= visors
leverage the ARMv7a Virtualization Extensions for accelerated per= formance
in CPU virtualization, but both of them are fundamentally different fromeach other.

Xvisor ARM is a complete monolithic hypervisor having o= ne common software
for host hardware access, CPU virtualization, and gue= st IO emulation. The
KVM ARM hypervisor is somewhere in between monolithic and microkernelizedhypervisors. In KVM ARM the host=A0 hardware access + CPU virtualization = is
one piece of software (i.e. Linux+KVM driver) wherease guest IO emula= tion
is another piece of software (i.e. QEMU).

The binary size of Xvisor = ARM for VExpress-A15 is 294 KB whereas that of
Linux KVM ARM is 2.1 MB. = In addition to this Xvisor ARM for VExpress-A15
runs with a modest memor= y usage of 8 MB (most of which is still free even
when Linux guest is running).

To have an apple to apple comparison w= e did few test on Realview-PB-A8 guest
emulated by both these hypervisor= s, such as:
Test1: Time taken to boot linux kernel
Test2: Time taken = to compute md5sum of a 1560 KB file
Test3: DMIPS obtained by running dhrystone

Native Linux for VExpress= -A15
Test1: 15 secs (Boot Time)
Test2: 38 secs (md5sum on 1560 KB)Test3: 153 DMIPS (or 270255 dhrystones per second)

Realview-PB-A8 L= inux Guest on Xvisor ARM for VExpress-A15
Test1: 10 secs (Boot Time)
Test2: 40 secs (md5sum on 1560 KB)
Test3: = 151 DMIPS (or 265486 dhrystones per second)

Realview-PB-A8 Linux Gue= st on KVM ARM for VExpress-A15
Test1: 30 secs (Boot Time)
Test2: 41 s= ecs (md5sum on 1560 KB)
Test3: 141 DMIPS (or 247737 dhrystones per second)

(Note: we have us= ed same linux images for running as guest on Xvisor ARM
and KVM ARM)
=
The above numbers clearly show that the monolithic nature of Xvisor ARM=
gives it a great performance advantage over KVM ARM even though both usehardware assisted CPU virtualization.

Xvisor ARM is able to boot mu= ltiple unmodified linux even without hardware
virtualization support but= KVM ARM needs ARMv7a virtualization extensions.

On real hardware specifically BeagleBoard-xM (OMAP3 @ 600 MHz) we get n= ear
native CPU performance without virtualization extensions (i.e. Nativ= e Linux
3.0.4 gives 1120 DMIPS whereas Linux 3.0.4 running as guest on X= visor ARM
gives 960 DMIPS)
--20cf307cff84adaeff04bf45f978-- --===============8197519526125896745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============8197519526125896745==-- From xen-arm-bounces@lists.xen.org Sat May 05 08:39:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 08: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 1SQaWb-0003Ry-P7; Sat, 05 May 2012 08: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 1SQaWa-0003Rk-Vg for xen-arm@lists.xen.org; Sat, 05 May 2012 08:39:33 +0000 Received: from [85.158.139.83:18551] by server-2.bemta-5.messagelabs.com id CC/08-17016-447E4AF4; Sat, 05 May 2012 08:39:32 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-16.tower-182.messagelabs.com!1336207169!19531849!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG, HTML_00_10,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5924 invoked from network); 5 May 2012 08:39:31 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vx0-f173.google.com) (209.85.220.173) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 08:39:31 -0000 Received: by vcbfl11 with SMTP id fl11so3230702vcb.32 for ; Sat, 05 May 2012 01:39:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=aVvFUQKqy83AAlIr8UOls1Pr3Fu3aa5cJ/kfegOSqak=; b=asbk5jbi4vg7d5uz0C3wquTKiRMRzd45Er7/oJtiV9fzBk9WiDgE020N6/fhJvBomy Rci8JasKzD4Xzk0sH5HCfgvO0KwUZSNWRCrx9QC2CHNWUl7ltAz+68b0lbdbTMRBrHJ4 huQFc3sMVPz6xmwrkM/lj8Ykjla2/dRrsxU7eYtaFS3zIktIfuxUgaaxkOHry2ynnyGT N+TZ+unjSLaYs7ETTKf0cvTpUMeWvmPeGVzbycvvFcH/H19uA81uD005lREUr947LqWw BKaJGaX/Kq5kQhT8QlYgeGEPlXKWZmFJOuCCYgTbDzDyj9wbCpl8Z8yz/yfYAcfVp5TZ 3Wbg== MIME-Version: 1.0 Received: by 10.52.66.40 with SMTP id c8mr3649528vdt.63.1336207169400; Sat, 05 May 2012 01:39:29 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 01:39:29 -0700 (PDT) X-Originating-IP: [14.97.5.37] Date: Sat, 5 May 2012 14:09:29 +0530 Message-ID: From: Anup Patel To: android-virt@lists.cs.columbia.edu, xen-arm@lists.xensource.com, xen-arm@lists.xen.org, Xvisor Devel X-Gm-Message-State: ALoCoQmz6k8ybDs+mc+989CP4nX+0R7EGMMLfLE4fFLl9URtDm+IPaAn2uDcsARrUIU3w8U3P5yu Subject: [XenARM] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8197519526125896745==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============8197519526125896745== Content-Type: multipart/alternative; boundary=20cf307cff84adaeff04bf45f978 --20cf307cff84adaeff04bf45f978 Content-Type: text/plain; charset=ISO-8859-1 This announcement is to show an apple to apple performance comparison between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. Both hypervisors leverage the ARMv7a Virtualization Extensions for accelerated performance in CPU virtualization, but both of them are fundamentally different from each other. Xvisor ARM is a complete monolithic hypervisor having one common software for host hardware access, CPU virtualization, and guest IO emulation. The KVM ARM hypervisor is somewhere in between monolithic and microkernelized hypervisors. In KVM ARM the host hardware access + CPU virtualization is one piece of software (i.e. Linux+KVM driver) wherease guest IO emulation is another piece of software (i.e. QEMU). The binary size of Xvisor ARM for VExpress-A15 is 294 KB whereas that of Linux KVM ARM is 2.1 MB. In addition to this Xvisor ARM for VExpress-A15 runs with a modest memory usage of 8 MB (most of which is still free even when Linux guest is running). To have an apple to apple comparison we did few test on Realview-PB-A8 guest emulated by both these hypervisors, such as: Test1: Time taken to boot linux kernel Test2: Time taken to compute md5sum of a 1560 KB file Test3: DMIPS obtained by running dhrystone Native Linux for VExpress-A15 Test1: 15 secs (Boot Time) Test2: 38 secs (md5sum on 1560 KB) Test3: 153 DMIPS (or 270255 dhrystones per second) Realview-PB-A8 Linux Guest on Xvisor ARM for VExpress-A15 Test1: 10 secs (Boot Time) Test2: 40 secs (md5sum on 1560 KB) Test3: 151 DMIPS (or 265486 dhrystones per second) Realview-PB-A8 Linux Guest on KVM ARM for VExpress-A15 Test1: 30 secs (Boot Time) Test2: 41 secs (md5sum on 1560 KB) Test3: 141 DMIPS (or 247737 dhrystones per second) (Note: we have used same linux images for running as guest on Xvisor ARM and KVM ARM) The above numbers clearly show that the monolithic nature of Xvisor ARM gives it a great performance advantage over KVM ARM even though both use hardware assisted CPU virtualization. Xvisor ARM is able to boot multiple unmodified linux even without hardware virtualization support but KVM ARM needs ARMv7a virtualization extensions. On real hardware specifically BeagleBoard-xM (OMAP3 @ 600 MHz) we get near native CPU performance without virtualization extensions (i.e. Native Linux 3.0.4 gives 1120 DMIPS whereas Linux 3.0.4 running as guest on Xvisor ARM gives 960 DMIPS) --20cf307cff84adaeff04bf45f978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This announcement is to show an apple to apple performance comparison betwe= en
Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. Both hyper= visors
leverage the ARMv7a Virtualization Extensions for accelerated per= formance
in CPU virtualization, but both of them are fundamentally different fromeach other.

Xvisor ARM is a complete monolithic hypervisor having o= ne common software
for host hardware access, CPU virtualization, and gue= st IO emulation. The
KVM ARM hypervisor is somewhere in between monolithic and microkernelizedhypervisors. In KVM ARM the host=A0 hardware access + CPU virtualization = is
one piece of software (i.e. Linux+KVM driver) wherease guest IO emula= tion
is another piece of software (i.e. QEMU).

The binary size of Xvisor = ARM for VExpress-A15 is 294 KB whereas that of
Linux KVM ARM is 2.1 MB. = In addition to this Xvisor ARM for VExpress-A15
runs with a modest memor= y usage of 8 MB (most of which is still free even
when Linux guest is running).

To have an apple to apple comparison w= e did few test on Realview-PB-A8 guest
emulated by both these hypervisor= s, such as:
Test1: Time taken to boot linux kernel
Test2: Time taken = to compute md5sum of a 1560 KB file
Test3: DMIPS obtained by running dhrystone

Native Linux for VExpress= -A15
Test1: 15 secs (Boot Time)
Test2: 38 secs (md5sum on 1560 KB)Test3: 153 DMIPS (or 270255 dhrystones per second)

Realview-PB-A8 L= inux Guest on Xvisor ARM for VExpress-A15
Test1: 10 secs (Boot Time)
Test2: 40 secs (md5sum on 1560 KB)
Test3: = 151 DMIPS (or 265486 dhrystones per second)

Realview-PB-A8 Linux Gue= st on KVM ARM for VExpress-A15
Test1: 30 secs (Boot Time)
Test2: 41 s= ecs (md5sum on 1560 KB)
Test3: 141 DMIPS (or 247737 dhrystones per second)

(Note: we have us= ed same linux images for running as guest on Xvisor ARM
and KVM ARM)
=
The above numbers clearly show that the monolithic nature of Xvisor ARM=
gives it a great performance advantage over KVM ARM even though both usehardware assisted CPU virtualization.

Xvisor ARM is able to boot mu= ltiple unmodified linux even without hardware
virtualization support but= KVM ARM needs ARMv7a virtualization extensions.

On real hardware specifically BeagleBoard-xM (OMAP3 @ 600 MHz) we get n= ear
native CPU performance without virtualization extensions (i.e. Nativ= e Linux
3.0.4 gives 1120 DMIPS whereas Linux 3.0.4 running as guest on X= visor ARM
gives 960 DMIPS)
--20cf307cff84adaeff04bf45f978-- --===============8197519526125896745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============8197519526125896745==-- From xen-arm-bounces@lists.xen.org Sat May 05 08:39:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 08: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 1SQaWb-0003Rt-MB; Sat, 05 May 2012 08:39:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQaWa-0003Rj-Q1 for xen-arm@lists.xensource.com; Sat, 05 May 2012 08:39:33 +0000 Received: from [85.158.143.99:58556] by server-3.bemta-4.messagelabs.com id 42/1C-05853-447E4AF4; Sat, 05 May 2012 08:39:32 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-2.tower-216.messagelabs.com!1336207169!21287697!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG, HTML_00_10,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18691 invoked from network); 5 May 2012 08:39: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; 5 May 2012 08:39:31 -0000 Received: by vbbfq11 with SMTP id fq11so3354133vbb.30 for ; Sat, 05 May 2012 01:39:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=aVvFUQKqy83AAlIr8UOls1Pr3Fu3aa5cJ/kfegOSqak=; b=H+mqcFBk/kI/t1owYQreygZ3eGGUWwIQ6FDMvUz3CxHHaGbCf9FiMbtivLby3gJSfm 4GhhDxEDWnR4ujapsJq4S1hYSjkrlTK6gZzqT26nAUqolVIlZkfU89YHelOuvFtDsAR9 qUFLOxHYHPTnHl7TX3J6GYT3JYKVJyE3VpK/vCJrxFLP+Bh140uZt4Q4mS3pWzJk8yyf QUk077cKZEIGhb7EmdESE+R0eO5Fz1ohttGC5ZzSpAOse8votekuki2cfvUnzDmVaoHs RyjXJ7KhZ7gHY/rXdc+uwh0Wm86KMm3kS3e6weIAf9vCykqiy7ZfYmBHeiqnwTwuwRRA iqUQ== MIME-Version: 1.0 Received: by 10.52.66.40 with SMTP id c8mr3649528vdt.63.1336207169400; Sat, 05 May 2012 01:39:29 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 01:39:29 -0700 (PDT) X-Originating-IP: [14.97.5.37] Date: Sat, 5 May 2012 14:09:29 +0530 Message-ID: From: Anup Patel To: android-virt@lists.cs.columbia.edu, xen-arm@lists.xensource.com, xen-arm@lists.xen.org, Xvisor Devel X-Gm-Message-State: ALoCoQmkgIEq2IX9BnEN79iGo8UnBrZVIWiT4QI2PKroDMx2JQFQ6dH5Ajbs1lqLP49dwl524gnp Subject: [XenARM] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1093705273732592162==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============1093705273732592162== Content-Type: multipart/alternative; boundary=20cf307cff84adaeff04bf45f978 --20cf307cff84adaeff04bf45f978 Content-Type: text/plain; charset=ISO-8859-1 This announcement is to show an apple to apple performance comparison between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. Both hypervisors leverage the ARMv7a Virtualization Extensions for accelerated performance in CPU virtualization, but both of them are fundamentally different from each other. Xvisor ARM is a complete monolithic hypervisor having one common software for host hardware access, CPU virtualization, and guest IO emulation. The KVM ARM hypervisor is somewhere in between monolithic and microkernelized hypervisors. In KVM ARM the host hardware access + CPU virtualization is one piece of software (i.e. Linux+KVM driver) wherease guest IO emulation is another piece of software (i.e. QEMU). The binary size of Xvisor ARM for VExpress-A15 is 294 KB whereas that of Linux KVM ARM is 2.1 MB. In addition to this Xvisor ARM for VExpress-A15 runs with a modest memory usage of 8 MB (most of which is still free even when Linux guest is running). To have an apple to apple comparison we did few test on Realview-PB-A8 guest emulated by both these hypervisors, such as: Test1: Time taken to boot linux kernel Test2: Time taken to compute md5sum of a 1560 KB file Test3: DMIPS obtained by running dhrystone Native Linux for VExpress-A15 Test1: 15 secs (Boot Time) Test2: 38 secs (md5sum on 1560 KB) Test3: 153 DMIPS (or 270255 dhrystones per second) Realview-PB-A8 Linux Guest on Xvisor ARM for VExpress-A15 Test1: 10 secs (Boot Time) Test2: 40 secs (md5sum on 1560 KB) Test3: 151 DMIPS (or 265486 dhrystones per second) Realview-PB-A8 Linux Guest on KVM ARM for VExpress-A15 Test1: 30 secs (Boot Time) Test2: 41 secs (md5sum on 1560 KB) Test3: 141 DMIPS (or 247737 dhrystones per second) (Note: we have used same linux images for running as guest on Xvisor ARM and KVM ARM) The above numbers clearly show that the monolithic nature of Xvisor ARM gives it a great performance advantage over KVM ARM even though both use hardware assisted CPU virtualization. Xvisor ARM is able to boot multiple unmodified linux even without hardware virtualization support but KVM ARM needs ARMv7a virtualization extensions. On real hardware specifically BeagleBoard-xM (OMAP3 @ 600 MHz) we get near native CPU performance without virtualization extensions (i.e. Native Linux 3.0.4 gives 1120 DMIPS whereas Linux 3.0.4 running as guest on Xvisor ARM gives 960 DMIPS) --20cf307cff84adaeff04bf45f978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This announcement is to show an apple to apple performance comparison betwe= en
Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. Both hyper= visors
leverage the ARMv7a Virtualization Extensions for accelerated per= formance
in CPU virtualization, but both of them are fundamentally different fromeach other.

Xvisor ARM is a complete monolithic hypervisor having o= ne common software
for host hardware access, CPU virtualization, and gue= st IO emulation. The
KVM ARM hypervisor is somewhere in between monolithic and microkernelizedhypervisors. In KVM ARM the host=A0 hardware access + CPU virtualization = is
one piece of software (i.e. Linux+KVM driver) wherease guest IO emula= tion
is another piece of software (i.e. QEMU).

The binary size of Xvisor = ARM for VExpress-A15 is 294 KB whereas that of
Linux KVM ARM is 2.1 MB. = In addition to this Xvisor ARM for VExpress-A15
runs with a modest memor= y usage of 8 MB (most of which is still free even
when Linux guest is running).

To have an apple to apple comparison w= e did few test on Realview-PB-A8 guest
emulated by both these hypervisor= s, such as:
Test1: Time taken to boot linux kernel
Test2: Time taken = to compute md5sum of a 1560 KB file
Test3: DMIPS obtained by running dhrystone

Native Linux for VExpress= -A15
Test1: 15 secs (Boot Time)
Test2: 38 secs (md5sum on 1560 KB)Test3: 153 DMIPS (or 270255 dhrystones per second)

Realview-PB-A8 L= inux Guest on Xvisor ARM for VExpress-A15
Test1: 10 secs (Boot Time)
Test2: 40 secs (md5sum on 1560 KB)
Test3: = 151 DMIPS (or 265486 dhrystones per second)

Realview-PB-A8 Linux Gue= st on KVM ARM for VExpress-A15
Test1: 30 secs (Boot Time)
Test2: 41 s= ecs (md5sum on 1560 KB)
Test3: 141 DMIPS (or 247737 dhrystones per second)

(Note: we have us= ed same linux images for running as guest on Xvisor ARM
and KVM ARM)
=
The above numbers clearly show that the monolithic nature of Xvisor ARM=
gives it a great performance advantage over KVM ARM even though both usehardware assisted CPU virtualization.

Xvisor ARM is able to boot mu= ltiple unmodified linux even without hardware
virtualization support but= KVM ARM needs ARMv7a virtualization extensions.

On real hardware specifically BeagleBoard-xM (OMAP3 @ 600 MHz) we get n= ear
native CPU performance without virtualization extensions (i.e. Nativ= e Linux
3.0.4 gives 1120 DMIPS whereas Linux 3.0.4 running as guest on X= visor ARM
gives 960 DMIPS)
--20cf307cff84adaeff04bf45f978-- --===============1093705273732592162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============1093705273732592162==-- From xen-arm-bounces@lists.xen.org Sat May 05 14:24:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 14: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 1SQfuS-0005Gq-Rr; Sat, 05 May 2012 14:24:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQfuR-0005Gc-HM for xen-arm@lists.xen.org; Sat, 05 May 2012 14:24:31 +0000 Received: from [85.158.139.83:27848] by server-8.bemta-5.messagelabs.com id 7D/80-26964-E1835AF4; Sat, 05 May 2012 14:24:30 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-15.tower-182.messagelabs.com!1336227867!26828765!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP,SUSPICIOUS_RECIPS X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15727 invoked from network); 5 May 2012 14:24:29 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vx0-f173.google.com) (209.85.220.173) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 14:24:29 -0000 Received: by vcbfl11 with SMTP id fl11so3340540vcb.32 for ; Sat, 05 May 2012 07:24:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/kw91gJabK+TjX48R0qhK+5LkWkDzsVunvhj79SfVLE=; b=Y/IaQZipjHV60pKBblkh7TVMan51LWrDWtQ0Dq1tbYnWEnUHQYJAFZ4/M54LHbmY7U vXXEfUYnRhOFGcg6ix9MCDEXHSIczjjmJCr5qb14IpHI04DZecISSfpzcJrtM2TccmVk 66tkhnwukFGp9a6l0cTQLKmsMKgeCXbTPyIX1hmNX9Ek5BnRM1/GpHtq7gbYZoKwB8e0 oOYMk2vfCh4toe42x0JeusaLrzfbHsPuC2cweIj/pAg+Ywq74XpCyrgJsR/SjmtAksfS gadgQKssiJxtOo0nVb+8JCQFFONPQjdY8d9yysxfYrhpw7d7HdKwoAQOov1lGYg+6UO7 FIrQ== MIME-Version: 1.0 Received: by 10.52.77.70 with SMTP id q6mr4036539vdw.61.1336227866992; Sat, 05 May 2012 07:24:26 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 07:24:26 -0700 (PDT) X-Originating-IP: [14.97.236.225] In-Reply-To: References:

Date: Sat, 5 May 2012 19:54:26 +0530 Message-ID: From: Anup Patel To: Peter Maydell X-Gm-Message-State: ALoCoQkDTS5IXP4hCnxWIIovWTzoAqXDKcoWJf52CBPHJsH3YHqxQPfZ0m9T/Tvhr6v/VWHoVp9L Cc: xen-arm@lists.xensource.com, Xvisor Devel , android-virt@lists.cs.columbia.edu, xen-arm@lists.xen.org Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3577990233579060662==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============3577990233579060662== Content-Type: multipart/alternative; boundary=20cf3071cfae59df0704bf4acb71 --20cf3071cfae59df0704bf4acb71 Content-Type: text/plain; charset=ISO-8859-1 Hi PMM, I agree we cannot predict real world performance based on performance on ARM fast models but if system A is performing better than system B no ARM fast model or QEMU then in real world system A will perform better than system B. Of-course in real world scale of difference in performance between system A and system B will differ. The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. Regards, --Anup On Sat, May 5, 2012 at 3:36 PM, Peter Maydell wrote: > 2012/5/5 Anup Patel : > > This announcement is to show an apple to apple performance comparison > > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. > > I would strongly caution against trying to do any performance/timing > type tests if you're still running on the ARM Fast Model -- they are > not representative of performance characteristics on hardware > and you really can't draw any conclusions about real world > performance by timing things on a model. It's quite easy to get > into a situation where all you're measuring is "does my code happen > to do a lot of some perfectly reasonable operation which happens > to be hard and slow to implement for the model?". > > (Also, KVM for ARM is still under development and we haven't > yet made several of the obvious performance improvements like > in-kernel irqchip and timer support, so it's not really a very > useful thing to compare against yet.) > > -- PMM > --20cf3071cfae59df0704bf4acb71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi PMM,

I agree we cannot predict real world performance based on pe= rformance on ARM fast models but if system A is performing better than syst= em B no ARM fast model or QEMU then in real world system A will perform bet= ter than system B. Of-course in real world scale of difference in performan= ce between system A and system B will differ.

The previous announcement only proves that Xvisor ARM is relatively bet= ter than KVM ARM.

Regards,
--Anup

On Sat, May 5, 2012 at 3:36 PM, Peter Maydell <peter.maydell@lin= aro.org> wrote:

2012/5/5 Anup Patel <anup@brainfault.org>:

> This announcement is to show an apple to apple perfo= rmance comparison
> between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model.

I would strongly caution against trying to do any performance/timing<= br> type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware
and you really can't draw any conclusions about real world
performance by timing things on a model. It's quite easy to get
into a situation where all you're measuring is "does my code happe= n
to do a lot of some perfectly reasonable operation which happens
to be hard and slow to implement for the model?".

(Also, KVM for ARM is still under development and we haven't
yet made several of the obvious performance improvements like
in-kernel irqchip and timer support, so it's not really a very
useful thing to compare against yet.)

-- PMM

--20cf3071cfae59df0704bf4acb71-- --===============3577990233579060662== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============3577990233579060662==-- From xen-arm-bounces@lists.xen.org Sat May 05 14:24:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 14: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 1SQfuS-0005Gq-Rr; Sat, 05 May 2012 14:24:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQfuR-0005Gc-HM for xen-arm@lists.xen.org; Sat, 05 May 2012 14:24:31 +0000 Received: from [85.158.139.83:27848] by server-8.bemta-5.messagelabs.com id 7D/80-26964-E1835AF4; Sat, 05 May 2012 14:24:30 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-15.tower-182.messagelabs.com!1336227867!26828765!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP,SUSPICIOUS_RECIPS X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15727 invoked from network); 5 May 2012 14:24:29 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vx0-f173.google.com) (209.85.220.173) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 14:24:29 -0000 Received: by vcbfl11 with SMTP id fl11so3340540vcb.32 for ; Sat, 05 May 2012 07:24:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/kw91gJabK+TjX48R0qhK+5LkWkDzsVunvhj79SfVLE=; b=Y/IaQZipjHV60pKBblkh7TVMan51LWrDWtQ0Dq1tbYnWEnUHQYJAFZ4/M54LHbmY7U vXXEfUYnRhOFGcg6ix9MCDEXHSIczjjmJCr5qb14IpHI04DZecISSfpzcJrtM2TccmVk 66tkhnwukFGp9a6l0cTQLKmsMKgeCXbTPyIX1hmNX9Ek5BnRM1/GpHtq7gbYZoKwB8e0 oOYMk2vfCh4toe42x0JeusaLrzfbHsPuC2cweIj/pAg+Ywq74XpCyrgJsR/SjmtAksfS gadgQKssiJxtOo0nVb+8JCQFFONPQjdY8d9yysxfYrhpw7d7HdKwoAQOov1lGYg+6UO7 FIrQ== MIME-Version: 1.0 Received: by 10.52.77.70 with SMTP id q6mr4036539vdw.61.1336227866992; Sat, 05 May 2012 07:24:26 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 07:24:26 -0700 (PDT) X-Originating-IP: [14.97.236.225] In-Reply-To: References:

On Sat, May 5, 2012 at 3:36 PM, Peter Maydell <peter.maydell@lin= aro.org> wrote:

2012/5/5 Anup Patel <anup@brainfault.org>:

> This announcement is to show an apple to apple perfo= rmance comparison
> between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model.

I would strongly caution against trying to do any performance/timing<= br> type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware
and you really can't draw any conclusions about real world
performance by timing things on a model. It's quite easy to get
into a situation where all you're measuring is "does my code happe= n
to do a lot of some perfectly reasonable operation which happens
to be hard and slow to implement for the model?".

(Also, KVM for ARM is still under development and we haven't
yet made several of the obvious performance improvements like
in-kernel irqchip and timer support, so it's not really a very
useful thing to compare against yet.)

-- PMM

--20cf3071cfae59df0704bf4acb71-- --===============3577990233579060662== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============3577990233579060662==-- From xen-arm-bounces@lists.xen.org Sat May 05 14:24:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 14: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 1SQfuS-0005Gl-Oi; Sat, 05 May 2012 14:24:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQfuR-0005Gb-5v for xen-arm@lists.xensource.com; Sat, 05 May 2012 14:24:31 +0000 Received: from [85.158.143.35:37744] by server-1.bemta-4.messagelabs.com id FA/3A-20925-E1835AF4; Sat, 05 May 2012 14:24:30 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1336227867!7654836!1 X-Originating-IP: [209.85.220.171] X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP,SUSPICIOUS_RECIPS X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31881 invoked from network); 5 May 2012 14:24:28 -0000 Received: from mail-vc0-f171.google.com (HELO mail-vx0-f171.google.com) (209.85.220.171) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 14:24:28 -0000 Received: by vcbfl15 with SMTP id fl15so3448472vcb.30 for ; Sat, 05 May 2012 07:24:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/kw91gJabK+TjX48R0qhK+5LkWkDzsVunvhj79SfVLE=; b=RPN4GpY5GuIYThmHaki/0HWoBiNzCzMU8Jriz7/8/DHa80BFt3EXPDKizLd6+DHEFf UfLq1iPMyrMIpgQB01+gBqqgnlEGJ67YLhX/p2nWqwFiUtWGXUNzwPdZAebQzgiQQwZv pX11LoelOmV6kHwuZh/peU4MKeVkV4nHby+g4w4plOv2ubgOO6wNlkjh4DLU2StnnVJF 7DZqO1uHyIn7sVK5FvXd6JVvmZF71ltZsn01YaFZ85uL0PxZ+xAseSuj5KAVGeC+c8Wv QF97k0LuQJvVAth7c+lSs9D9pvYCtABBp+qTGz4e6IIt8iLTkk3aszWBQu6HEEP48mPX K9Dw== MIME-Version: 1.0 Received: by 10.52.77.70 with SMTP id q6mr4036539vdw.61.1336227866992; Sat, 05 May 2012 07:24:26 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 07:24:26 -0700 (PDT) X-Originating-IP: [14.97.236.225] In-Reply-To: References:

Date: Sat, 5 May 2012 19:54:26 +0530 Message-ID: From: Anup Patel To: Peter Maydell X-Gm-Message-State: ALoCoQlFK9YzS6miiYGZIdMXusr0ANI+40fZgn/NduYaTEByJhtXZA+dLwWQvGdSZa4H7KNGSj95 Cc: xen-arm@lists.xensource.com, Xvisor Devel , android-virt@lists.cs.columbia.edu, xen-arm@lists.xen.org Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7286160056739692310==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============7286160056739692310== Content-Type: multipart/alternative; boundary=20cf3071cfae59df0704bf4acb71 --20cf3071cfae59df0704bf4acb71 Content-Type: text/plain; charset=ISO-8859-1 Hi PMM, I agree we cannot predict real world performance based on performance on ARM fast models but if system A is performing better than system B no ARM fast model or QEMU then in real world system A will perform better than system B. Of-course in real world scale of difference in performance between system A and system B will differ. The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. Regards, --Anup On Sat, May 5, 2012 at 3:36 PM, Peter Maydell wrote: > 2012/5/5 Anup Patel : > > This announcement is to show an apple to apple performance comparison > > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. > > I would strongly caution against trying to do any performance/timing > type tests if you're still running on the ARM Fast Model -- they are > not representative of performance characteristics on hardware > and you really can't draw any conclusions about real world > performance by timing things on a model. It's quite easy to get > into a situation where all you're measuring is "does my code happen > to do a lot of some perfectly reasonable operation which happens > to be hard and slow to implement for the model?". > > (Also, KVM for ARM is still under development and we haven't > yet made several of the obvious performance improvements like > in-kernel irqchip and timer support, so it's not really a very > useful thing to compare against yet.) > > -- PMM > --20cf3071cfae59df0704bf4acb71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi PMM,

I agree we cannot predict real world performance based on pe= rformance on ARM fast models but if system A is performing better than syst= em B no ARM fast model or QEMU then in real world system A will perform bet= ter than system B. Of-course in real world scale of difference in performan= ce between system A and system B will differ.

The previous announcement only proves that Xvisor ARM is relatively bet= ter than KVM ARM.

Regards,
--Anup

On Sat, May 5, 2012 at 3:36 PM, Peter Maydell <peter.maydell@lin= aro.org> wrote:

2012/5/5 Anup Patel <anup@brainfault.org>:

> This announcement is to show an apple to apple perfo= rmance comparison
> between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model.

I would strongly caution against trying to do any performance/timing<= br> type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware
and you really can't draw any conclusions about real world
performance by timing things on a model. It's quite easy to get
into a situation where all you're measuring is "does my code happe= n
to do a lot of some perfectly reasonable operation which happens
to be hard and slow to implement for the model?".

(Also, KVM for ARM is still under development and we haven't
yet made several of the obvious performance improvements like
in-kernel irqchip and timer support, so it's not really a very
useful thing to compare against yet.)

-- PMM

--20cf3071cfae59df0704bf4acb71-- --===============7286160056739692310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============7286160056739692310==-- From xen-arm-bounces@lists.xen.org Sat May 05 14:24:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 14: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 1SQfuS-0005Gl-Oi; Sat, 05 May 2012 14:24:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQfuR-0005Gb-5v for xen-arm@lists.xensource.com; Sat, 05 May 2012 14:24:31 +0000 Received: from [85.158.143.35:37744] by server-1.bemta-4.messagelabs.com id FA/3A-20925-E1835AF4; Sat, 05 May 2012 14:24:30 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1336227867!7654836!1 X-Originating-IP: [209.85.220.171] X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP,SUSPICIOUS_RECIPS X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31881 invoked from network); 5 May 2012 14:24:28 -0000 Received: from mail-vc0-f171.google.com (HELO mail-vx0-f171.google.com) (209.85.220.171) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 14:24:28 -0000 Received: by vcbfl15 with SMTP id fl15so3448472vcb.30 for ; Sat, 05 May 2012 07:24:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/kw91gJabK+TjX48R0qhK+5LkWkDzsVunvhj79SfVLE=; b=RPN4GpY5GuIYThmHaki/0HWoBiNzCzMU8Jriz7/8/DHa80BFt3EXPDKizLd6+DHEFf UfLq1iPMyrMIpgQB01+gBqqgnlEGJ67YLhX/p2nWqwFiUtWGXUNzwPdZAebQzgiQQwZv pX11LoelOmV6kHwuZh/peU4MKeVkV4nHby+g4w4plOv2ubgOO6wNlkjh4DLU2StnnVJF 7DZqO1uHyIn7sVK5FvXd6JVvmZF71ltZsn01YaFZ85uL0PxZ+xAseSuj5KAVGeC+c8Wv QF97k0LuQJvVAth7c+lSs9D9pvYCtABBp+qTGz4e6IIt8iLTkk3aszWBQu6HEEP48mPX K9Dw== MIME-Version: 1.0 Received: by 10.52.77.70 with SMTP id q6mr4036539vdw.61.1336227866992; Sat, 05 May 2012 07:24:26 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 07:24:26 -0700 (PDT) X-Originating-IP: [14.97.236.225] In-Reply-To: References:

On Sat, May 5, 2012 at 3:36 PM, Peter Maydell <peter.maydell@lin= aro.org> wrote:

2012/5/5 Anup Patel <anup@brainfault.org>:

> This announcement is to show an apple to apple perfo= rmance comparison
> between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model.

I would strongly caution against trying to do any performance/timing<= br> type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware
and you really can't draw any conclusions about real world
performance by timing things on a model. It's quite easy to get
into a situation where all you're measuring is "does my code happe= n
to do a lot of some perfectly reasonable operation which happens
to be hard and slow to implement for the model?".

(Also, KVM for ARM is still under development and we haven't
yet made several of the obvious performance improvements like
in-kernel irqchip and timer support, so it's not really a very
useful thing to compare against yet.)

-- PMM

--20cf3071cfae59df0704bf4acb71-- --===============7286160056739692310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============7286160056739692310==-- From xen-arm-bounces@lists.xen.org Sat May 05 14:31:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 14: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 1SQg1M-0005Nr-Id; Sat, 05 May 2012 14:31:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQg1L-0005Ni-Qi for xen-arm@lists.xensource.com; Sat, 05 May 2012 14:31:40 +0000 Received: from [193.109.254.147:27241] by server-8.bemta-14.messagelabs.com id 20/F1-23244-AC935AF4; Sat, 05 May 2012 14:31:38 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-3.tower-27.messagelabs.com!1336228296!7854013!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP,SUSPICIOUS_RECIPS X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31929 invoked from network); 5 May 2012 14:31:37 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 14:31:37 -0000 Received: by vbbfq11 with SMTP id fq11so3473815vbb.30 for ; Sat, 05 May 2012 07:31:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=neokgXkN4HCORfsXlEu2nlj6+TyYLRQcAsX322aTnck=; b=PPrN2jFs1TA70Ur8I2hjJQyvkr+V83GU7frM6zh5NI9ORaogRtDF56UwqIqO0v6rt2 ydJRmQAss2Es1Vbw/Kb9iDYVa+DVpjaW1OQcE/OT6l1L7lc3373Aj9JXEbQgvz3wLfNU ziqkI5CJmvAi7BI1LvJ4Qfxo99oM8R5TCNs4C84+cT2rSC0Ru8Fs0Mvh3/GlxKxVG76T 3YEhQ6Rfw1xSnmRUbPNGtyNTTGWhs3/khVN5og3MTnhsUf/u727+QASqdx1NEhfx0uiR twNHZg0pEL1IuJAzY4wkxrKbLItjW63XRrSuDEAX2BnuRVhdiSNdtUAluVJmwgmWs5Zw VKOg== MIME-Version: 1.0 Received: by 10.52.66.40 with SMTP id c8mr4037216vdt.63.1336228296299; Sat, 05 May 2012 07:31:36 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 07:31:36 -0700 (PDT) X-Originating-IP: [14.97.236.225] In-Reply-To: References:

Date: Sat, 5 May 2012 20:01:36 +0530 Message-ID: From: Anup Patel To: Peter Maydell X-Gm-Message-State: ALoCoQnDSpUQCDtsqGHISICsK84MkloiMxu6KeP7oCxjQM/emzOkdaOVN1GXX8aqDpnoSZq7P4Dy Cc: xen-arm@lists.xensource.com, Xvisor Devel , android-virt@lists.cs.columbia.edu, xen-arm@lists.xen.org Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0150189639036946253==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============0150189639036946253== Content-Type: multipart/alternative; boundary=20cf307cff84f0961704bf4ae410 --20cf307cff84f0961704bf4ae410 Content-Type: text/plain; charset=ISO-8859-1 Hi PMM, Also in my-view even if we have in-kernel emulation of irqchip and timer still Xvisor ARM will be performing better than KVM ARM because amount of code path traversed in KVM ARM will always be more. (Please note my-view about in-kernel emulation is totally based on code flow comparison of Xvisor ARM emulation and possible KVM ARM in-kernel emulation) Regards, --Anup On Sat, May 5, 2012 at 7:54 PM, Anup Patel wrote: > Hi PMM, > > I agree we cannot predict real world performance based on performance on > ARM fast models but if system A is performing better than system B no ARM > fast model or QEMU then in real world system A will perform better than > system B. Of-course in real world scale of difference in performance > between system A and system B will differ. > > The previous announcement only proves that Xvisor ARM is relatively better > than KVM ARM. > > Regards, > --Anup > > > On Sat, May 5, 2012 at 3:36 PM, Peter Maydell wrote: > >> 2012/5/5 Anup Patel : >> > This announcement is to show an apple to apple performance comparison >> > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. >> >> I would strongly caution against trying to do any performance/timing >> type tests if you're still running on the ARM Fast Model -- they are >> not representative of performance characteristics on hardware >> and you really can't draw any conclusions about real world >> performance by timing things on a model. It's quite easy to get >> into a situation where all you're measuring is "does my code happen >> to do a lot of some perfectly reasonable operation which happens >> to be hard and slow to implement for the model?". >> >> (Also, KVM for ARM is still under development and we haven't >> yet made several of the obvious performance improvements like >> in-kernel irqchip and timer support, so it's not really a very >> useful thing to compare against yet.) >> >> -- PMM >> > > --20cf307cff84f0961704bf4ae410 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi PMM,

Also in my-view even if we have in-kernel emulation of irqch= ip and timer still Xvisor ARM will be performing better than KVM ARM becaus= e amount of code path traversed in KVM ARM will always be more.

(Please note my-view about in-kernel emulation is totally based on code flo= w comparison of Xvisor ARM emulation and possible KVM ARM in-kernel emulati= on)

Regards,
--Anup

On Sat, May= 5, 2012 at 7:54 PM, Anup Patel <anup@brainfault.org> wrot= e:

Hi PMM,

I agree we cannot predict rea= l world performance based on performance on ARM fast models but if system A= is performing better than system B no ARM fast model or QEMU then in real = world system A will perform better than system B. Of-course in real world s= cale of difference in performance between system A and system B will differ= .

The previous announcement only proves that Xvisor ARM is relatively bet= ter than KVM ARM.

Regards,
--Anup

On Sat, May 5, 2012 at 3:36 PM, = Peter Maydell <peter.maydell@linaro.org> wrote:

2012/5/5 Anup Patel <anup@brainfault.org>:

> This announcement is to show an apple to apple performance compar= ison
> between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model.

I would strongly caution against trying to do any performance/timing<= br> type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware
and you really can't draw any conclusions about real world
performance by timing things on a model. It's quite easy to get
into a situation where all you're measuring is "does my code happe= n
to do a lot of some perfectly reasonable operation which happens
to be hard and slow to implement for the model?".

(Also, KVM for ARM is still under development and we haven't
yet made several of the obvious performance improvements like
in-kernel irqchip and timer support, so it's not really a very
useful thing to compare against yet.)

-- PMM

--20cf307cff84f0961704bf4ae410-- --===============0150189639036946253== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============0150189639036946253==-- From xen-arm-bounces@lists.xen.org Sat May 05 14:31:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 14: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 1SQg1M-0005Nr-Id; Sat, 05 May 2012 14:31:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQg1L-0005Ni-Qi for xen-arm@lists.xensource.com; Sat, 05 May 2012 14:31:40 +0000 Received: from [193.109.254.147:27241] by server-8.bemta-14.messagelabs.com id 20/F1-23244-AC935AF4; Sat, 05 May 2012 14:31:38 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-3.tower-27.messagelabs.com!1336228296!7854013!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP,SUSPICIOUS_RECIPS X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31929 invoked from network); 5 May 2012 14:31:37 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 14:31:37 -0000 Received: by vbbfq11 with SMTP id fq11so3473815vbb.30 for ; Sat, 05 May 2012 07:31:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=neokgXkN4HCORfsXlEu2nlj6+TyYLRQcAsX322aTnck=; b=PPrN2jFs1TA70Ur8I2hjJQyvkr+V83GU7frM6zh5NI9ORaogRtDF56UwqIqO0v6rt2 ydJRmQAss2Es1Vbw/Kb9iDYVa+DVpjaW1OQcE/OT6l1L7lc3373Aj9JXEbQgvz3wLfNU ziqkI5CJmvAi7BI1LvJ4Qfxo99oM8R5TCNs4C84+cT2rSC0Ru8Fs0Mvh3/GlxKxVG76T 3YEhQ6Rfw1xSnmRUbPNGtyNTTGWhs3/khVN5og3MTnhsUf/u727+QASqdx1NEhfx0uiR twNHZg0pEL1IuJAzY4wkxrKbLItjW63XRrSuDEAX2BnuRVhdiSNdtUAluVJmwgmWs5Zw VKOg== MIME-Version: 1.0 Received: by 10.52.66.40 with SMTP id c8mr4037216vdt.63.1336228296299; Sat, 05 May 2012 07:31:36 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 07:31:36 -0700 (PDT) X-Originating-IP: [14.97.236.225] In-Reply-To: References:

On Sat, May= 5, 2012 at 7:54 PM, Anup Patel <anup@brainfault.org> wrot= e:

Hi PMM,

I agree we cannot predict rea= l world performance based on performance on ARM fast models but if system A= is performing better than system B no ARM fast model or QEMU then in real = world system A will perform better than system B. Of-course in real world s= cale of difference in performance between system A and system B will differ= .

The previous announcement only proves that Xvisor ARM is relatively bet= ter than KVM ARM.

Regards,
--Anup

On Sat, May 5, 2012 at 3:36 PM, = Peter Maydell <peter.maydell@linaro.org> wrote:

2012/5/5 Anup Patel <anup@brainfault.org>:

> This announcement is to show an apple to apple performance compar= ison
> between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model.

I would strongly caution against trying to do any performance/timing<= br> type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware
and you really can't draw any conclusions about real world
performance by timing things on a model. It's quite easy to get
into a situation where all you're measuring is "does my code happe= n
to do a lot of some perfectly reasonable operation which happens
to be hard and slow to implement for the model?".

(Also, KVM for ARM is still under development and we haven't
yet made several of the obvious performance improvements like
in-kernel irqchip and timer support, so it's not really a very
useful thing to compare against yet.)

-- PMM

--20cf307cff84f0961704bf4ae410-- --===============0150189639036946253== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============0150189639036946253==-- From xen-arm-bounces@lists.xen.org Sat May 05 14:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 14: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 1SQg1M-0005Nw-LZ; Sat, 05 May 2012 14:31:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQg1L-0005Ng-RD for xen-arm@lists.xen.org; Sat, 05 May 2012 14:31:40 +0000 Received: from [85.158.139.83:56071] by server-4.bemta-5.messagelabs.com id A9/FC-10788-AC935AF4; Sat, 05 May 2012 14:31:38 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-6.tower-182.messagelabs.com!1336228296!23032086!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP,SUSPICIOUS_RECIPS X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25735 invoked from network); 5 May 2012 14:31:37 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 14:31:37 -0000 Received: by vbbfs19 with SMTP id fs19so3311348vbb.32 for ; Sat, 05 May 2012 07:31:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=neokgXkN4HCORfsXlEu2nlj6+TyYLRQcAsX322aTnck=; b=KpuGQfgP+K/6v7SArSGJVAXfLeiYIPYFqoLKL23Qqmf40j1wRSzuw6jIHL9t8ml0EX NNkQYhyr2ctjaBe055QVqscZvBEJnSnb8RGd5W2HWR8FnqsM4JIKBTaBk6enj6QQKEq7 AJcJ0C00AJr9bhxca34pfvLzu5pvRHDLfjmGaFUnudLW/e3ysR2xJ8+bSMdqdcEh067C rcQwxkJY37gbXowQ8bfJnj7HyvKpVNVyYTF5AXPmYekPx1KGkKWWCDxikRgtWGPAhiAK P+SPrObG2u1ZMrmBaYzTKCpITYwQwptshmAhFLJIq3UufYj3wS4j5mX71e+2J/zVkK7o TguA== MIME-Version: 1.0 Received: by 10.52.66.40 with SMTP id c8mr4037216vdt.63.1336228296299; Sat, 05 May 2012 07:31:36 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 07:31:36 -0700 (PDT) X-Originating-IP: [14.97.236.225] In-Reply-To: References:

Date: Sat, 5 May 2012 20:01:36 +0530 Message-ID: From: Anup Patel To: Peter Maydell X-Gm-Message-State: ALoCoQk/u/zoKY+g1KNMQHN1jPrS2MzC1GxEKkBlVWxePLGaC4yblTLLg5WbP+1e+CYfuH4RJEbV Cc: xen-arm@lists.xensource.com, Xvisor Devel , android-virt@lists.cs.columbia.edu, xen-arm@lists.xen.org Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5007895495105606872==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============5007895495105606872== Content-Type: multipart/alternative; boundary=20cf307cff84f0961704bf4ae410 --20cf307cff84f0961704bf4ae410 Content-Type: text/plain; charset=ISO-8859-1 Hi PMM, Also in my-view even if we have in-kernel emulation of irqchip and timer still Xvisor ARM will be performing better than KVM ARM because amount of code path traversed in KVM ARM will always be more. (Please note my-view about in-kernel emulation is totally based on code flow comparison of Xvisor ARM emulation and possible KVM ARM in-kernel emulation) Regards, --Anup On Sat, May 5, 2012 at 7:54 PM, Anup Patel wrote: > Hi PMM, > > I agree we cannot predict real world performance based on performance on > ARM fast models but if system A is performing better than system B no ARM > fast model or QEMU then in real world system A will perform better than > system B. Of-course in real world scale of difference in performance > between system A and system B will differ. > > The previous announcement only proves that Xvisor ARM is relatively better > than KVM ARM. > > Regards, > --Anup > > > On Sat, May 5, 2012 at 3:36 PM, Peter Maydell wrote: > >> 2012/5/5 Anup Patel : >> > This announcement is to show an apple to apple performance comparison >> > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. >> >> I would strongly caution against trying to do any performance/timing >> type tests if you're still running on the ARM Fast Model -- they are >> not representative of performance characteristics on hardware >> and you really can't draw any conclusions about real world >> performance by timing things on a model. It's quite easy to get >> into a situation where all you're measuring is "does my code happen >> to do a lot of some perfectly reasonable operation which happens >> to be hard and slow to implement for the model?". >> >> (Also, KVM for ARM is still under development and we haven't >> yet made several of the obvious performance improvements like >> in-kernel irqchip and timer support, so it's not really a very >> useful thing to compare against yet.) >> >> -- PMM >> > > --20cf307cff84f0961704bf4ae410 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi PMM,

Also in my-view even if we have in-kernel emulation of irqch= ip and timer still Xvisor ARM will be performing better than KVM ARM becaus= e amount of code path traversed in KVM ARM will always be more.

(Please note my-view about in-kernel emulation is totally based on code flo= w comparison of Xvisor ARM emulation and possible KVM ARM in-kernel emulati= on)

Regards,
--Anup

On Sat, May= 5, 2012 at 7:54 PM, Anup Patel <anup@brainfault.org> wrot= e:

Hi PMM,

I agree we cannot predict rea= l world performance based on performance on ARM fast models but if system A= is performing better than system B no ARM fast model or QEMU then in real = world system A will perform better than system B. Of-course in real world s= cale of difference in performance between system A and system B will differ= .

The previous announcement only proves that Xvisor ARM is relatively bet= ter than KVM ARM.

Regards,
--Anup

On Sat, May 5, 2012 at 3:36 PM, = Peter Maydell <peter.maydell@linaro.org> wrote:

2012/5/5 Anup Patel <anup@brainfault.org>:

> This announcement is to show an apple to apple performance compar= ison
> between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model.

I would strongly caution against trying to do any performance/timing<= br> type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware
and you really can't draw any conclusions about real world
performance by timing things on a model. It's quite easy to get
into a situation where all you're measuring is "does my code happe= n
to do a lot of some perfectly reasonable operation which happens
to be hard and slow to implement for the model?".

(Also, KVM for ARM is still under development and we haven't
yet made several of the obvious performance improvements like
in-kernel irqchip and timer support, so it's not really a very
useful thing to compare against yet.)

-- PMM

--20cf307cff84f0961704bf4ae410-- --===============5007895495105606872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============5007895495105606872==-- From xen-arm-bounces@lists.xen.org Sat May 05 14:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 14: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 1SQg1M-0005Nw-LZ; Sat, 05 May 2012 14:31:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQg1L-0005Ng-RD for xen-arm@lists.xen.org; Sat, 05 May 2012 14:31:40 +0000 Received: from [85.158.139.83:56071] by server-4.bemta-5.messagelabs.com id A9/FC-10788-AC935AF4; Sat, 05 May 2012 14:31:38 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-6.tower-182.messagelabs.com!1336228296!23032086!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP,SUSPICIOUS_RECIPS X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25735 invoked from network); 5 May 2012 14:31:37 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 14:31:37 -0000 Received: by vbbfs19 with SMTP id fs19so3311348vbb.32 for ; Sat, 05 May 2012 07:31:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=neokgXkN4HCORfsXlEu2nlj6+TyYLRQcAsX322aTnck=; b=KpuGQfgP+K/6v7SArSGJVAXfLeiYIPYFqoLKL23Qqmf40j1wRSzuw6jIHL9t8ml0EX NNkQYhyr2ctjaBe055QVqscZvBEJnSnb8RGd5W2HWR8FnqsM4JIKBTaBk6enj6QQKEq7 AJcJ0C00AJr9bhxca34pfvLzu5pvRHDLfjmGaFUnudLW/e3ysR2xJ8+bSMdqdcEh067C rcQwxkJY37gbXowQ8bfJnj7HyvKpVNVyYTF5AXPmYekPx1KGkKWWCDxikRgtWGPAhiAK P+SPrObG2u1ZMrmBaYzTKCpITYwQwptshmAhFLJIq3UufYj3wS4j5mX71e+2J/zVkK7o TguA== MIME-Version: 1.0 Received: by 10.52.66.40 with SMTP id c8mr4037216vdt.63.1336228296299; Sat, 05 May 2012 07:31:36 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 07:31:36 -0700 (PDT) X-Originating-IP: [14.97.236.225] In-Reply-To: References:

On Sat, May= 5, 2012 at 7:54 PM, Anup Patel <anup@brainfault.org> wrot= e:

Hi PMM,

I agree we cannot predict rea= l world performance based on performance on ARM fast models but if system A= is performing better than system B no ARM fast model or QEMU then in real = world system A will perform better than system B. Of-course in real world s= cale of difference in performance between system A and system B will differ= .

The previous announcement only proves that Xvisor ARM is relatively bet= ter than KVM ARM.

Regards,
--Anup

On Sat, May 5, 2012 at 3:36 PM, = Peter Maydell <peter.maydell@linaro.org> wrote:

2012/5/5 Anup Patel <anup@brainfault.org>:

> This announcement is to show an apple to apple performance compar= ison
> between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model.

I would strongly caution against trying to do any performance/timing<= br> type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware
and you really can't draw any conclusions about real world
performance by timing things on a model. It's quite easy to get
into a situation where all you're measuring is "does my code happe= n
to do a lot of some perfectly reasonable operation which happens
to be hard and slow to implement for the model?".

(Also, KVM for ARM is still under development and we haven't
yet made several of the obvious performance improvements like
in-kernel irqchip and timer support, so it's not really a very
useful thing to compare against yet.)

-- PMM

--20cf307cff84f0961704bf4ae410-- --===============5007895495105606872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============5007895495105606872==-- From xen-arm-bounces@lists.xen.org Sun May 06 04:22:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 04:22: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 1SQsza-0005kp-EM; Sun, 06 May 2012 04:22:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQszY-0005kb-Eq for xen-arm@lists.xen.org; Sun, 06 May 2012 04:22:40 +0000 Received: from [85.158.138.51:62370] by server-3.bemta-3.messagelabs.com id F9/1B-04048-F8CF5AF4; Sun, 06 May 2012 04:22:39 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-13.tower-174.messagelabs.com!1336278156!14498348!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7440 invoked from network); 6 May 2012 04:22:37 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 04:22:37 -0000 Received: by vbbfs19 with SMTP id fs19so3538875vbb.32 for ; Sat, 05 May 2012 21:22:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=v/JKPiYHPCYLseg3t9kMD90xKfjbqnnyAW8n7J3ANiM=; b=e9ErJCXEfBayI3sgZFzvZSFC4LKxxn4OXcSS5p283YdIbxcE5itCG3X5LBE0xyc9t0 JKN1mmNr4DyUgReAeL7LS4fCKBC8o0ZdicvLKlCO1tStUb/+Ota2KAwLporjgHSppAll lQcJs6xLfpDBk4BqMJ5ozpdbd4V1KPq5o5LoJZUrSYvCu/gaDFHgQWElyAcIOtOmm7K5 h7gCSGklZuO7cLwl0+icY2sMdgVja5w2xWhOkyhRaCg/VAlTySaDmzmHJ29XMK51wuLv nEpoJIxCwCWrXapv+Vlj7tXbm+ih6LEw8GpfomPUcg+SwTqPP/07rmBfpFLCq28u7bAc 9K+w== MIME-Version: 1.0 Received: by 10.52.77.70 with SMTP id q6mr4755366vdw.61.1336278155750; Sat, 05 May 2012 21:22:35 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 21:22:35 -0700 (PDT) X-Originating-IP: [14.97.202.243] In-Reply-To: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> References:

<20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> Date: Sun, 6 May 2012 09:52:35 +0530 Message-ID: From: Anup Patel To: Marc Zyngier X-Gm-Message-State: ALoCoQk6YwDgeo1csc2xb5neBn2Z0ACDklwRQVNif6/AFa0Yr7aRK2A1jklNUBh2UU3OxPENHEPH Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4507386533311281941==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============4507386533311281941== Content-Type: multipart/alternative; boundary=20cf3071cfaecb6c3804bf56804b --20cf3071cfaecb6c3804bf56804b Content-Type: text/plain; charset=ISO-8859-1 Hi Marc, We must understand that the claimed best performing hypervisor today is a complete monolithic hypervisor (i.e. VMware ESX server). The Xvisor vision is to have GPLv2 monolithic hypervisor. Our point is that KVM approach to virtualization is not optimal one and you will end-up putting more and more things in-kernel. Also can you give example of a code sequence which is faster on model and slower in real world. As far as I know ARM fast models are internally TLM based models and If a TLM based model is emulating a timer chip of X clock then it is quite precise X clock. Ofcourse CPU emulation and computation power will be less compared to real world. To see this behaviour try to boot linux on Fast model or QEMU and leave it for hours and come back see the time elapsed, you will definitely see same amount of time elapsed as real world. The results in the announcemnt are not baseless we have quite amount reasons to believe Xvisor ARM will perform better than KVM ARM in real-world too. Regards, Anup Patel On Sat, May 5, 2012 at 8:44 PM, Marc Zyngier wrote: > On Sat, 5 May 2012 15:31:36 +0100 > Anup Patel wrote: > > > Hi PMM, > > > > Also in my-view even if we have in-kernel emulation of irqchip and timer > still Xvisor ARM will be performing better than KVM ARM because amount of > code path traversed in KVM ARM will always be more. > > > > (Please note my-view about in-kernel emulation is totally based on code > flow comparison of Xvisor ARM emulation and possible KVM ARM in-kernel > emulation) > > > > Sweet. Can I borrow your crystal ball? > > M. > > > On Sat, May 5, 2012 at 7:54 PM, Anup Patel anup@brainfault.org>> wrote: > > Hi PMM, > > > > I agree we cannot predict real world performance based on performance on > ARM fast models but if system A is performing better than system B no ARM > fast model or QEMU then in real world system A will perform better than > system B. Of-course in real world scale of difference in performance > between system A and system B will differ. > > > > The previous announcement only proves that Xvisor ARM is relatively > better than KVM ARM. > > > > Regards, > > --Anup > > > > > > On Sat, May 5, 2012 at 3:36 PM, Peter Maydell > wrote: > > 2012/5/5 Anup Patel >: > > > This announcement is to show an apple to apple performance comparison > > > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. > > > > I would strongly caution against trying to do any performance/timing > > type tests if you're still running on the ARM Fast Model -- they are > > not representative of performance characteristics on hardware > > and you really can't draw any conclusions about real world > > performance by timing things on a model. It's quite easy to get > > into a situation where all you're measuring is "does my code happen > > to do a lot of some perfectly reasonable operation which happens > > to be hard and slow to implement for the model?". > > > > (Also, KVM for ARM is still under development and we haven't > > yet made several of the obvious performance improvements like > > in-kernel irqchip and timer support, so it's not really a very > > useful thing to compare against yet.) > > > > -- PMM > > > > > > > > -- > I'm the slime oozin' out from your TV set... > > --20cf3071cfaecb6c3804bf56804b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marc,

We must understand that the claimed best performing hypervi= sor today is a complete monolithic hypervisor (i.e. VMware ESX server). The= Xvisor vision is to have GPLv2 monolithic hypervisor. Our point is that KV= M approach to virtualization is not optimal one and you will end-up putting= more and more things in-kernel.

Also can you give example of a code sequence which is faster on model a= nd slower in real world. As far as I know ARM fast models are internally TL= M based models and If a TLM based model is emulating a timer chip of X cloc= k then it is quite precise X clock. Ofcourse CPU emulation and computation = power will be less compared to real world. To see this behaviour try to boo= t linux on Fast model or QEMU and leave it for hours and come back see the = time elapsed, you will definitely see same amount of time elapsed as real w= orld.

The results in the announcemnt are not baseless we have quite amount re= asons to believe Xvisor ARM will perform better than KVM ARM in real-world = too.

Regards,
Anup Patel

On Sat= , May 5, 2012 at 8:44 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:

On Sat, 5 May 2012 15:31:36 +0100

Anup Patel <anu= p@brainfault.org> wrote:

> Hi PMM,
>

> Also in my-view even if we have in-kernel emul= ation of irqchip and timer still Xvisor ARM will be performing better than = KVM ARM because amount of code path traversed in KVM ARM will always be mor= e.
>
> (Please note my-view about in-kernel emulation is totally based on cod= e flow comparison of Xvisor ARM emulation and possible KVM ARM in-kernel em= ulation)
>

Sweet. Can I borrow your crystal ball?

=A0 =A0 =A0 =A0M.

> On Sat, May 5, 2012 at 7:54 PM, Anup Patel <anup@brainfault.org<mailto:anup@brainfault.org>> wrote:
> Hi PMM,
>
> I agree we cannot predict real world performance based on performance = on ARM fast models but if system A is performing better than system B no AR= M fast model or QEMU then in real world system A will perform better than s= ystem B. Of-course in real world scale of difference in performance between= system A and system B will differ.
>
> The previous announcement only proves that Xvisor ARM is relatively be= tter than KVM ARM.
>
> Regards,
> --Anup
>
>

> On Sat, May 5, 2012 at 3:36 PM, Peter Maydell <peter.maydell@linaro.org<mailto:peter.maydell@linaro.org>> = wrote:
> 2012/5/5 Anup Patel <anup@br= ainfault.org<mailto:anup@brai= nfault.org>>:

> > This announcement is to show an apple to= apple performance comparison
> > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model= .
>
> I would strongly caution against trying to do any performance/timing > type tests if you're still running on the ARM Fast Model -- they a= re
> not representative of performance characteristics on hardware
> and you really can't draw any conclusions about real world
> performance by timing things on a model. It's quite easy to get > into a situation where all you're measuring is "does my code = happen
> to do a lot of some perfectly reasonable operation which happens
> to be hard and slow to implement for the model?".
>
> (Also, KVM for ARM is still under development and we haven't
> yet made several of the obvious performance improvements like
> in-kernel irqchip and timer support, so it's not really a very
> useful thing to compare against yet.)
>
> -- PMM
>
>

--
I'm the slime oozin' out from your TV set...

--20cf3071cfaecb6c3804bf56804b-- --===============4507386533311281941== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============4507386533311281941==-- From xen-arm-bounces@lists.xen.org Sun May 06 04:22:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 04:22: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 1SQsza-0005kp-EM; Sun, 06 May 2012 04:22:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQszY-0005kb-Eq for xen-arm@lists.xen.org; Sun, 06 May 2012 04:22:40 +0000 Received: from [85.158.138.51:62370] by server-3.bemta-3.messagelabs.com id F9/1B-04048-F8CF5AF4; Sun, 06 May 2012 04:22:39 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-13.tower-174.messagelabs.com!1336278156!14498348!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7440 invoked from network); 6 May 2012 04:22:37 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 04:22:37 -0000 Received: by vbbfs19 with SMTP id fs19so3538875vbb.32 for ; Sat, 05 May 2012 21:22:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=v/JKPiYHPCYLseg3t9kMD90xKfjbqnnyAW8n7J3ANiM=; b=e9ErJCXEfBayI3sgZFzvZSFC4LKxxn4OXcSS5p283YdIbxcE5itCG3X5LBE0xyc9t0 JKN1mmNr4DyUgReAeL7LS4fCKBC8o0ZdicvLKlCO1tStUb/+Ota2KAwLporjgHSppAll lQcJs6xLfpDBk4BqMJ5ozpdbd4V1KPq5o5LoJZUrSYvCu/gaDFHgQWElyAcIOtOmm7K5 h7gCSGklZuO7cLwl0+icY2sMdgVja5w2xWhOkyhRaCg/VAlTySaDmzmHJ29XMK51wuLv nEpoJIxCwCWrXapv+Vlj7tXbm+ih6LEw8GpfomPUcg+SwTqPP/07rmBfpFLCq28u7bAc 9K+w== MIME-Version: 1.0 Received: by 10.52.77.70 with SMTP id q6mr4755366vdw.61.1336278155750; Sat, 05 May 2012 21:22:35 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 21:22:35 -0700 (PDT) X-Originating-IP: [14.97.202.243] In-Reply-To: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> References:

On Sat= , May 5, 2012 at 8:44 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:

On Sat, 5 May 2012 15:31:36 +0100

Anup Patel <anu= p@brainfault.org> wrote:

> Hi PMM,
>

> Also in my-view even if we have in-kernel emul= ation of irqchip and timer still Xvisor ARM will be performing better than = KVM ARM because amount of code path traversed in KVM ARM will always be mor= e.
>
> (Please note my-view about in-kernel emulation is totally based on cod= e flow comparison of Xvisor ARM emulation and possible KVM ARM in-kernel em= ulation)
>

Sweet. Can I borrow your crystal ball?

=A0 =A0 =A0 =A0M.

> On Sat, May 5, 2012 at 7:54 PM, Anup Patel <anup@brainfault.org<mailto:anup@brainfault.org>> wrote:
> Hi PMM,
>
> I agree we cannot predict real world performance based on performance = on ARM fast models but if system A is performing better than system B no AR= M fast model or QEMU then in real world system A will perform better than s= ystem B. Of-course in real world scale of difference in performance between= system A and system B will differ.
>
> The previous announcement only proves that Xvisor ARM is relatively be= tter than KVM ARM.
>
> Regards,
> --Anup
>
>

> On Sat, May 5, 2012 at 3:36 PM, Peter Maydell <peter.maydell@linaro.org<mailto:peter.maydell@linaro.org>> = wrote:
> 2012/5/5 Anup Patel <anup@br= ainfault.org<mailto:anup@brai= nfault.org>>:

> > This announcement is to show an apple to= apple performance comparison
> > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model= .
>
> I would strongly caution against trying to do any performance/timing > type tests if you're still running on the ARM Fast Model -- they a= re
> not representative of performance characteristics on hardware
> and you really can't draw any conclusions about real world
> performance by timing things on a model. It's quite easy to get > into a situation where all you're measuring is "does my code = happen
> to do a lot of some perfectly reasonable operation which happens
> to be hard and slow to implement for the model?".
>
> (Also, KVM for ARM is still under development and we haven't
> yet made several of the obvious performance improvements like
> in-kernel irqchip and timer support, so it's not really a very
> useful thing to compare against yet.)
>
> -- PMM
>
>

--
I'm the slime oozin' out from your TV set...

--20cf3071cfaecb6c3804bf56804b-- --===============4507386533311281941== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============4507386533311281941==-- From xen-arm-bounces@lists.xen.org Sun May 06 04:22:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 04: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 1SQszZ-0005kk-BD; Sun, 06 May 2012 04:22:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQszX-0005ka-W4 for xen-arm@lists.xensource.com; Sun, 06 May 2012 04:22:40 +0000 Received: from [85.158.143.99:58749] by server-1.bemta-4.messagelabs.com id 6E/77-20925-F8CF5AF4; Sun, 06 May 2012 04:22:39 +0000 X-Env-Sender: anup@brainfault.org X-Msg-Ref: server-16.tower-216.messagelabs.com!1336278156!15474105!1 X-Originating-IP: [209.85.220.171] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17168 invoked from network); 6 May 2012 04:22:37 -0000 Received: from mail-vc0-f171.google.com (HELO mail-vx0-f171.google.com) (209.85.220.171) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 04:22:37 -0000 Received: by vcbfl15 with SMTP id fl15so3681698vcb.30 for ; Sat, 05 May 2012 21:22:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=v/JKPiYHPCYLseg3t9kMD90xKfjbqnnyAW8n7J3ANiM=; b=R1afaYX7tvHkARUmShcpix+LKxzNrYpdkCcj55utFzAfvAvpFvKplpFG6uJgGFN7Sz 30i2Ver1kgNB258+YR06ZLU4dT+6JAG4Q0/wr7iCp/5skBX30kXvxsO5xPdMj2yJ0jVK mHj5rFiHQIUrhFXTJGYy4PiU7wjmV9a/6wPHQ9aw/5j2o3QM+eJVYVWcB9UFlPHAz34f y/d5hd13bn8p7O1zRe0loqbeRQHLYm5yHE5DRlhYhKi/upjRdY4ndEC5M+MpwhIoqC+R HjtmUqGeFw55enCLg4gp/Wu18cY+B8d2xMsXaXtzn8pACNW+HONVCouG4lszC/iLMNBz qlog== MIME-Version: 1.0 Received: by 10.52.77.70 with SMTP id q6mr4755366vdw.61.1336278155750; Sat, 05 May 2012 21:22:35 -0700 (PDT) Received: by 10.220.140.15 with HTTP; Sat, 5 May 2012 21:22:35 -0700 (PDT) X-Originating-IP: [14.97.202.243] In-Reply-To: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> References:

<20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> Date: Sun, 6 May 2012 09:52:35 +0530 Message-ID: From: Anup Patel To: Marc Zyngier X-Gm-Message-State: ALoCoQmhfhXxg7CtTi4Ib9cow6y8xwmDk4gutY005JUdk0KbSnfhOyvvoKg7ySffaXbTFFWln3Yp Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen ARM development

Hi,

Please inform the status of Xen-ARM for Cortex-A8 CPU's on FM= E from ARM.

These links here
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions
&
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtual= ization_Extensions/FastModels

give information about the dom0 running on FME= .

Though Xen-ARM is avai= lable for Cortex-A9 with KVM Virt extensions for Tegra2Harmony,

Cortex-A8 is widely us= ed, and I would like to know the status.

<= span style=3D"font-family:comic sans ms,sans-serif">So, Kindly inform, so t= hat, we could learn more about/from it.
--

=E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D

--bcaec52e5f9ba4d3dd04c04dfee5-- --===============4526074649606535884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============4526074649606535884==-- From xen-arm-bounces@lists.xen.org Fri May 18 11:38:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 11:38: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 1SVLWC-0004iL-C5; Fri, 18 May 2012 11:38:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVLWB-0004iA-5a for xen-arm@lists.xensource.com; Fri, 18 May 2012 11:38:47 +0000 Received: from [85.158.138.51:52531] by server-2.bemta-3.messagelabs.com id EC/7A-09269-6C436BF4; Fri, 18 May 2012 11:38:46 +0000 X-Env-Sender: post4pavan@gmail.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1337341124!27882911!1 X-Originating-IP: [209.85.161.171] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9385 invoked from network); 18 May 2012 11:38:45 -0000 Received: from mail-gg0-f171.google.com (HELO mail-gg0-f171.google.com) (209.85.161.171) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 11:38:45 -0000 Received: by ggmi1 with SMTP id i1so3412855ggm.30 for ; Fri, 18 May 2012 04:38:44 -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=dyAWgcLeUW+iQjKa8U+P6vAI2xEYwP8VvpycFM8tLkI=; b=CxadUw/SrmoaSLQsfmj9JXpnP6rqLqO8pxGy12mpxIUuSjQrO0xUUOsKDj+WsxkOSv 8DIgKGajv4VyrKKmdGuPujxqmUFHxR54CjunXCP2+9c8O35DHjvzz16UQB8Kf1SA3yUZ IQ1hvVcdkMRfDW+5KTDMY+j+E3cqC9GfcEkl47rgTIdmgmwG9dc3A/apOlZ5tPUNfm+G dvPpOvp1o8UUtbYOuvB47cbr7TLDWYKPmTK0Qu2OAAmtZbH8wFZ+Goo1e2Jp0CwOwhtc 5Z7fV9pbK3s72luCqqspWFEe8Wr2m3DB685iOZmaekxWrYv6YNXu2PsPBWvIbzwrzidK tINQ== MIME-Version: 1.0 Received: by 10.43.46.196 with SMTP id up4mr6803295icb.41.1337341124072; Fri, 18 May 2012 04:38:44 -0700 (PDT) Received: by 10.42.241.131 with HTTP; Fri, 18 May 2012 04:38:43 -0700 (PDT) Date: Fri, 18 May 2012 17:08:43 +0530 Message-ID: From: Krishna Pavan To: Xen Subject: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4526074649606535884==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============4526074649606535884== Content-Type: multipart/alternative; boundary=bcaec52e5f9ba4d3dd04c04dfee5 --bcaec52e5f9ba4d3dd04c04dfee5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Please inform the status of Xen-ARM for Cortex-A8 CPU's on FME from ARM. These links here http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions & http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastModel= s give information about the dom0 running on FME. Though Xen-ARM is available for Cortex-A9 with KVM Virt extensions for Tegra2Harmony, Cortex-A8 is widely used, and I would like to know the status. So, Kindly inform, so that, we could learn more about/from it. --=20 =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D --bcaec52e5f9ba4d3dd04c04dfee5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D

--bcaec52e5f9ba4d3dd04c04dfee5-- --===============4526074649606535884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============4526074649606535884==-- From xen-arm-bounces@lists.xen.org Fri May 18 12:51:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 12: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 1SVMe1-00077v-US; Fri, 18 May 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 1SVMe0-00077q-FM for xen-arm@lists.xensource.com; Fri, 18 May 2012 12:50:56 +0000 Received: from [85.158.143.99:22142] by server-2.bemta-4.messagelabs.com id 73/74-12211-FA546BF4; Fri, 18 May 2012 12:50:55 +0000 X-Env-Sender: post4pavan@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1337345436!23382854!1 X-Originating-IP: [209.85.213.171] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_23,ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDcwNDk3NjMgKHRpbWVvdXQp\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7195 invoked from network); 18 May 2012 12:50:37 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 12:50:37 -0000 Received: by yenq11 with SMTP id q11so3456076yen.30 for ; Fri, 18 May 2012 05:50: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=nVqwCMdf+EXpYRJYg+/WzzopZZBVSn0wSVhbmUV+sp8=; b=WZvPJeSbfxecAu0iSazTrSZ/2nbmxd9zJ99y7sFaupWjyJfffhd1HL5DYQei+0LFPs 3iAtQ3Opk1uwPDQShjriHgxetN1Iko8sX8PIaMrtfQrSNioVavdkhKLpp1kDE9O22aiv mvJyIVKGkNCsnuLA47NaegqkHdRHgdoo96iOA7cLtyUgYnZVwwxvhyB5iG3kqpH7cdzR r6xN2pZRubQzDobRvP4167LhzA/WiYwS8PsNZk4+OE7iKbhLkKiUPuvPCZHZLVdXNap/ d2kw1IOmm8LO8E/PhJqvNuqkVBW+6ye8lqlNjdpdgweYRcDH42Vsp7IIntN70B987HOm A2+g== MIME-Version: 1.0 Received: by 10.50.173.8 with SMTP id bg8mr426496igc.24.1337345434881; Fri, 18 May 2012 05:50:34 -0700 (PDT) Received: by 10.42.241.131 with HTTP; Fri, 18 May 2012 05:50:34 -0700 (PDT) In-Reply-To: <56C765CA-598E-465B-AC3A-7BC594CEEC2B@gmail.com> References: <56C765CA-598E-465B-AC3A-7BC594CEEC2B@gmail.com> Date: Fri, 18 May 2012 18:20:34 +0530 Message-ID: From: Krishna Pavan To: Seehwan Yoo Cc: Xen Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3573771826812960623==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============3573771826812960623== Content-Type: multipart/alternative; boundary=e89a8f647711968fd804c04efff2 --e89a8f647711968fd804c04efff2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is it? Good & Great! Have you been able to run two guests on FME or on the target! Because, you need Virt_Extensions on for Cortex-A8, to run directly on target right? On Fri, May 18, 2012 at 5:41 PM, Seehwan Yoo wrote: > Hi, > We've been working with Xen-ARM_pv for cortex-a8. > We've run two guest Linux. > Our H/W platform is with s5pc100 that uses cortex-a8 core. > > > * Seehwan Yoo * > Ph. D. candidate > > T + 82-2-3290-3639 > F + 82-2-922-6341 > E shyoo@os.korea.ac.kr > [image: logo] Home Page | > Blog | OSVirtual > OSLab. =E2=80=A2 Korea Univ. =E2=80=A2 Seoul =E2=80=A2 South Korea > > 2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E=91=EC=84=B1: > > Hi, > > Please inform the status of Xen-ARM for Cortex-A8 CPU's on FME from ARM. > > These links here > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions > & > > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastMod= els > > give information about the dom0 running on FME. > > Though Xen-ARM is available for Cortex-A9 with KVM Virt extensions for > Tegra2Harmony, > > Cortex-A8 is widely used, and I would like to know the status. > > So, Kindly inform, so that, we could learn more about/from it. > -- > =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D > > _______________________________________________ > Xen-arm mailing list > Xen-arm@lists.xen.org > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm > > > --=20 =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D --e89a8f647711968fd804c04efff2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Is it= ?

Good & Great!

Have you been able to run two guests on FME or= on the target!
Because, you need Virt= _Extensions on for Cortex-A8, to run directly on target right?

On Fri, May 18, 2012 at 5:41 PM, Seehwan Yoo <= span dir=3D"ltr"><seehwan.yoo@gmail.com> wrote:

Hi,=C2= =A0
We've been working with Xen-ARM_pv for cortex-a8.
We&#= 39;ve run two guest Linux.=C2=A0

Our H/W platform is with s5pc100 that uses cortex-a8 core.
<= br>

=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
=C2=A0 =20 =C2=A0Seehwan Yoo
=20 =20 =C2=A0=C2=A0Ph. D. candidate

=20 =20 =C2=A0T=C2=A0+ 82-2-3290-3639
=20 =20 =C2=A0F=C2=A0+ 82-2-922-6341
=20 =20 =C2=A0E=C2=A0shyoo@os.korea.ac.kr
=20 =C2=A0
=20 = Home Page=C2=A0|=C2=A0=20 Blog=C2=A0|=C2=A0=20 OSVirtual=20
=C2=A0 =C2=A0OSLab.=C2=A0=E2=80=A2=20 Korea Univ. =E2=80=A2=20 Seoul=C2=A0=C2=A0=E2=80=A2= =20 South Korea=20

2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E= =91=EC=84=B1:

Hi,

Please inform the status of Xen-ARM for Cortex= -A8 CPU's on FME from ARM.

These links here
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualizatio= n_Extensions
&
http://wiki.xen.org/wiki/Xen_= ARMv7_with_Virtualization_Extensions/FastModels

give information about the dom0 running on FME= .

Though Xen-ARM is avai= lable for Cortex-A9 with KVM Virt extensions for Tegra2Harmony,

Cortex-A8 is widely us= ed, and I would like to know the status.

<= span style=3D"font-family:comic sans ms,sans-serif">So, Kindly inform, so t= hat, we could learn more about/from it.
--
=E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D

_______________________________________________
Xen-arm mailing list
= Xen-arm@lists.xe= n.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm=

=E2=9C=89 Regards :: Kri= shna Pavan =E2=9C=8D

--e89a8f647711968fd804c04efff2-- --===============3573771826812960623== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============3573771826812960623==-- From xen-arm-bounces@lists.xen.org Fri May 18 12:51:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 12: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 1SVMe1-00077v-US; Fri, 18 May 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 1SVMe0-00077q-FM for xen-arm@lists.xensource.com; Fri, 18 May 2012 12:50:56 +0000 Received: from [85.158.143.99:22142] by server-2.bemta-4.messagelabs.com id 73/74-12211-FA546BF4; Fri, 18 May 2012 12:50:55 +0000 X-Env-Sender: post4pavan@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1337345436!23382854!1 X-Originating-IP: [209.85.213.171] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_23,ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDcwNDk3NjMgKHRpbWVvdXQp\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7195 invoked from network); 18 May 2012 12:50:37 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 12:50:37 -0000 Received: by yenq11 with SMTP id q11so3456076yen.30 for ; Fri, 18 May 2012 05:50: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=nVqwCMdf+EXpYRJYg+/WzzopZZBVSn0wSVhbmUV+sp8=; b=WZvPJeSbfxecAu0iSazTrSZ/2nbmxd9zJ99y7sFaupWjyJfffhd1HL5DYQei+0LFPs 3iAtQ3Opk1uwPDQShjriHgxetN1Iko8sX8PIaMrtfQrSNioVavdkhKLpp1kDE9O22aiv mvJyIVKGkNCsnuLA47NaegqkHdRHgdoo96iOA7cLtyUgYnZVwwxvhyB5iG3kqpH7cdzR r6xN2pZRubQzDobRvP4167LhzA/WiYwS8PsNZk4+OE7iKbhLkKiUPuvPCZHZLVdXNap/ d2kw1IOmm8LO8E/PhJqvNuqkVBW+6ye8lqlNjdpdgweYRcDH42Vsp7IIntN70B987HOm A2+g== MIME-Version: 1.0 Received: by 10.50.173.8 with SMTP id bg8mr426496igc.24.1337345434881; Fri, 18 May 2012 05:50:34 -0700 (PDT) Received: by 10.42.241.131 with HTTP; Fri, 18 May 2012 05:50:34 -0700 (PDT) In-Reply-To: <56C765CA-598E-465B-AC3A-7BC594CEEC2B@gmail.com> References: <56C765CA-598E-465B-AC3A-7BC594CEEC2B@gmail.com> Date: Fri, 18 May 2012 18:20:34 +0530 Message-ID: From: Krishna Pavan To: Seehwan Yoo Cc: Xen Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3573771826812960623==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============3573771826812960623== Content-Type: multipart/alternative; boundary=e89a8f647711968fd804c04efff2 --e89a8f647711968fd804c04efff2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is it? Good & Great! Have you been able to run two guests on FME or on the target! Because, you need Virt_Extensions on for Cortex-A8, to run directly on target right? On Fri, May 18, 2012 at 5:41 PM, Seehwan Yoo wrote: > Hi, > We've been working with Xen-ARM_pv for cortex-a8. > We've run two guest Linux. > Our H/W platform is with s5pc100 that uses cortex-a8 core. > > > * Seehwan Yoo * > Ph. D. candidate > > T + 82-2-3290-3639 > F + 82-2-922-6341 > E shyoo@os.korea.ac.kr > [image: logo] Home Page | > Blog | OSVirtual > OSLab. =E2=80=A2 Korea Univ. =E2=80=A2 Seoul =E2=80=A2 South Korea > > 2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E=91=EC=84=B1: > > Hi, > > Please inform the status of Xen-ARM for Cortex-A8 CPU's on FME from ARM. > > These links here > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions > & > > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastMod= els > > give information about the dom0 running on FME. > > Though Xen-ARM is available for Cortex-A9 with KVM Virt extensions for > Tegra2Harmony, > > Cortex-A8 is widely used, and I would like to know the status. > > So, Kindly inform, so that, we could learn more about/from it. > -- > =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D > > _______________________________________________ > Xen-arm mailing list > Xen-arm@lists.xen.org > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm > > > --=20 =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D --e89a8f647711968fd804c04efff2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Is it= ?

Good & Great!

Have you been able to run two guests on FME or= on the target!
Because, you need Virt= _Extensions on for Cortex-A8, to run directly on target right?

On Fri, May 18, 2012 at 5:41 PM, Seehwan Yoo <= span dir=3D"ltr"><seehwan.yoo@gmail.com> wrote:

Hi,=C2= =A0
We've been working with Xen-ARM_pv for cortex-a8.
We&#= 39;ve run two guest Linux.=C2=A0

Our H/W platform is with s5pc100 that uses cortex-a8 core.
<= br>

=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
=C2=A0 =20 =C2=A0Seehwan Yoo
=20 =20 =C2=A0=C2=A0Ph. D. candidate

=20 =20 =C2=A0T=C2=A0+ 82-2-3290-3639
=20 =20 =C2=A0F=C2=A0+ 82-2-922-6341
=20 =20 =C2=A0E=C2=A0shyoo@os.korea.ac.kr
=20 =C2=A0
=20 = Home Page=C2=A0|=C2=A0=20 Blog=C2=A0|=C2=A0=20 OSVirtual=20
=C2=A0 =C2=A0OSLab.=C2=A0=E2=80=A2=20 Korea Univ. =E2=80=A2=20 Seoul=C2=A0=C2=A0=E2=80=A2= =20 South Korea=20

2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E= =91=EC=84=B1:

Hi,

Please inform the status of Xen-ARM for Cortex= -A8 CPU's on FME from ARM.

These links here
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualizatio= n_Extensions
&
http://wiki.xen.org/wiki/Xen_= ARMv7_with_Virtualization_Extensions/FastModels

give information about the dom0 running on FME= .

Though Xen-ARM is avai= lable for Cortex-A9 with KVM Virt extensions for Tegra2Harmony,

Cortex-A8 is widely us= ed, and I would like to know the status.

<= span style=3D"font-family:comic sans ms,sans-serif">So, Kindly inform, so t= hat, we could learn more about/from it.
--
=E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D

_______________________________________________
Xen-arm mailing list
= Xen-arm@lists.xe= n.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm=

=E2=9C=89 Regards :: Kri= shna Pavan =E2=9C=8D

--e89a8f647711968fd804c04efff2-- --===============3573771826812960623== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============3573771826812960623==-- From xen-arm-bounces@lists.xen.org Fri May 18 12:51:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 12: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 1SVMeH-00078e-28; Fri, 18 May 2012 12:51:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVMeE-00078R-Tw for xen-arm@lists.xensource.com; Fri, 18 May 2012 12:51:11 +0000 Received: from [85.158.139.83:32217] by server-9.bemta-5.messagelabs.com id 4E/8E-09826-EB546BF4; Fri, 18 May 2012 12:51:10 +0000 X-Env-Sender: seehwan.yoo@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1337345458!28406207!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_23,ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDcwNDU1MDQgKHRpbWVvdXQp\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30556 invoked from network); 18 May 2012 12:50:59 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 12:50:59 -0000 Received: by obfk16 with SMTP id k16so5207973obf.30 for ; Fri, 18 May 2012 05:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=EjNR/LtB+wf65CtnUKT0V3evXdPWuNZm7Eesc4hzl48=; b=xOYK1yg9TOugaJuvpmFfCp6fhbrK8ySWcbm+TfKzmCJCXR+BCX9+enoRfbssEqsXdq 5JIrAtSDihQRQwowqPbB57MCmnrijmvAVhXeMt8ag3GqJG+i14V64Qb7ikUxrfw6dcvb xZWlG/pQtVIWZhqmLH3Z1F6O+xqEXU+WQvB0iJk2VY/Lvxa1f7szVS3NQk7C1c+4cXnE 76POlmOuz4XyJGf3q4RZ6PL2hycW7cYICqMzTW2Fflmi8N4s54wm7apfXlLrdSg3tbGG 3Ucx4hfrccJK9boaUrzKSoXOzHtixnH1fqq7hUHA9l57+xHFekb2QNXa4hJ9cICD0ZQw fNIg== Received: by 10.182.115.1 with SMTP id jk1mr10283239obb.75.1337345455375; Fri, 18 May 2012 05:50:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.121.105 with HTTP; Fri, 18 May 2012 05:50:34 -0700 (PDT) In-Reply-To: <56C765CA-598E-465B-AC3A-7BC594CEEC2B@gmail.com> References: <56C765CA-598E-465B-AC3A-7BC594CEEC2B@gmail.com> From: See-Hwan Yoo Date: Fri, 18 May 2012 21:50:34 +0900 Message-ID: To: Krishna Pavan Cc: Xen Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: shyoo@os.korea.ac.kr List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4825243388580487539==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============4825243388580487539== Content-Type: multipart/alternative; boundary=f46d044516e1cf44b704c04f0014 --f46d044516e1cf44b704c04f0014 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oops, I'm sorry, I misunderstood the question. I'm not working with FME. 2012/5/18 Seehwan Yoo > Hi, > We've been working with Xen-ARM_pv for cortex-a8. > We've run two guest Linux. > Our H/W platform is with s5pc100 that uses cortex-a8 core. > > > * Seehwan Yoo * > Ph. D. candidate > > T + 82-2-3290-3639 > F + 82-2-922-6341 > E shyoo@os.korea.ac.kr > [image: logo] Home Page | > Blog | OSVirtual > OSLab. =E2=80=A2 Korea Univ. =E2=80=A2 Seoul =E2=80=A2 South Korea > > 2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E=91=EC=84=B1: > > Hi, > > Please inform the status of Xen-ARM for Cortex-A8 CPU's on FME from ARM. > > These links here > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions > & > > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastMod= els > > give information about the dom0 running on FME. > > Though Xen-ARM is available for Cortex-A9 with KVM Virt extensions for > Tegra2Harmony, > > Cortex-A8 is widely used, and I would like to know the status. > > So, Kindly inform, so that, we could learn more about/from it. > -- > =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D > > _______________________________________________ > Xen-arm mailing list > Xen-arm@lists.xen.org > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm > > > --f46d044516e1cf44b704c04f0014 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Oops,

I'm sorry, I misunderstood the question.

I'm not working with FME.

=C2=A0

2012/5/18 Seehwan Yoo <seehwan.yoo@gmail.com>

Hi,=C2=A0
We'v= e been working with Xen-ARM_pv for cortex-a8.

We've run two guest Linux.=C2=A0
Our H/W platform is wit= h s5pc100 that uses cortex-a8 core.

=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
=C2=A0 =20 =C2=A0Seehwan Yoo
=20 =20 =C2=A0=C2=A0Ph. D. candidate

=20 =20 =C2=A0T=C2=A0+ 82-2-3290-3639
=20 =20 =C2=A0F=C2=A0+ 82-2-922-6341
=20 =20 =C2=A0E=C2=A0shyoo@os.korea.ac.kr
=20 =C2=A0
=20 = Home Page=C2=A0|=C2=A0=20 Blog=C2=A0|=C2=A0=20 OSVirtual=20
=C2=A0 =C2=A0OSLab.=C2=A0=E2=80=A2=20 Korea Univ. =E2=80=A2=20 Seoul=C2=A0=C2=A0=E2=80=A2= =20 South Korea=20

2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E= =91=EC=84=B1:

Hi,

Please inform the status of Xen-ARM for Cortex= -A8 CPU's on FME from ARM.

These links here
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualizatio= n_Extensions
&
http://wiki.xen.org/wiki/Xen_= ARMv7_with_Virtualization_Extensions/FastModels

give information about the dom0 running on FME= .

Though Xen-ARM is avai= lable for Cortex-A9 with KVM Virt extensions for Tegra2Harmony,

Cortex-A8 is widely us= ed, and I would like to know the status.

<= span style=3D"font-family:comic sans ms,sans-serif">So, Kindly inform, so t= hat, we could learn more about/from it.
--
=E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D

_______________________________________________
Xen-arm mailing list
= Xen-arm@lists.xe= n.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm=

--f46d044516e1cf44b704c04f0014-- --===============4825243388580487539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============4825243388580487539==-- From xen-arm-bounces@lists.xen.org Fri May 18 12:51:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 12: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 1SVMeH-00078e-28; Fri, 18 May 2012 12:51:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVMeE-00078R-Tw for xen-arm@lists.xensource.com; Fri, 18 May 2012 12:51:11 +0000 Received: from [85.158.139.83:32217] by server-9.bemta-5.messagelabs.com id 4E/8E-09826-EB546BF4; Fri, 18 May 2012 12:51:10 +0000 X-Env-Sender: seehwan.yoo@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1337345458!28406207!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_23,ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDcwNDU1MDQgKHRpbWVvdXQp\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30556 invoked from network); 18 May 2012 12:50:59 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 12:50:59 -0000 Received: by obfk16 with SMTP id k16so5207973obf.30 for ; Fri, 18 May 2012 05:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=EjNR/LtB+wf65CtnUKT0V3evXdPWuNZm7Eesc4hzl48=; b=xOYK1yg9TOugaJuvpmFfCp6fhbrK8ySWcbm+TfKzmCJCXR+BCX9+enoRfbssEqsXdq 5JIrAtSDihQRQwowqPbB57MCmnrijmvAVhXeMt8ag3GqJG+i14V64Qb7ikUxrfw6dcvb xZWlG/pQtVIWZhqmLH3Z1F6O+xqEXU+WQvB0iJk2VY/Lvxa1f7szVS3NQk7C1c+4cXnE 76POlmOuz4XyJGf3q4RZ6PL2hycW7cYICqMzTW2Fflmi8N4s54wm7apfXlLrdSg3tbGG 3Ucx4hfrccJK9boaUrzKSoXOzHtixnH1fqq7hUHA9l57+xHFekb2QNXa4hJ9cICD0ZQw fNIg== Received: by 10.182.115.1 with SMTP id jk1mr10283239obb.75.1337345455375; Fri, 18 May 2012 05:50:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.121.105 with HTTP; Fri, 18 May 2012 05:50:34 -0700 (PDT) In-Reply-To: <56C765CA-598E-465B-AC3A-7BC594CEEC2B@gmail.com> References: <56C765CA-598E-465B-AC3A-7BC594CEEC2B@gmail.com> From: See-Hwan Yoo Date: Fri, 18 May 2012 21:50:34 +0900 Message-ID: To: Krishna Pavan Cc: Xen Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: shyoo@os.korea.ac.kr List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4825243388580487539==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============4825243388580487539== Content-Type: multipart/alternative; boundary=f46d044516e1cf44b704c04f0014 --f46d044516e1cf44b704c04f0014 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oops, I'm sorry, I misunderstood the question. I'm not working with FME. 2012/5/18 Seehwan Yoo > Hi, > We've been working with Xen-ARM_pv for cortex-a8. > We've run two guest Linux. > Our H/W platform is with s5pc100 that uses cortex-a8 core. > > > * Seehwan Yoo * > Ph. D. candidate > > T + 82-2-3290-3639 > F + 82-2-922-6341 > E shyoo@os.korea.ac.kr > [image: logo] Home Page | > Blog | OSVirtual > OSLab. =E2=80=A2 Korea Univ. =E2=80=A2 Seoul =E2=80=A2 South Korea > > 2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E=91=EC=84=B1: > > Hi, > > Please inform the status of Xen-ARM for Cortex-A8 CPU's on FME from ARM. > > These links here > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions > & > > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastMod= els > > give information about the dom0 running on FME. > > Though Xen-ARM is available for Cortex-A9 with KVM Virt extensions for > Tegra2Harmony, > > Cortex-A8 is widely used, and I would like to know the status. > > So, Kindly inform, so that, we could learn more about/from it. > -- > =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D > > _______________________________________________ > Xen-arm mailing list > Xen-arm@lists.xen.org > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm > > > --f46d044516e1cf44b704c04f0014 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Oops,

I'm sorry, I misunderstood the question.

I'm not working with FME.

=C2=A0

2012/5/18 Seehwan Yoo <seehwan.yoo@gmail.com>

Hi,=C2=A0
We'v= e been working with Xen-ARM_pv for cortex-a8.

We've run two guest Linux.=C2=A0
Our H/W platform is wit= h s5pc100 that uses cortex-a8 core.

=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
=C2=A0 =20 =C2=A0Seehwan Yoo
=20 =20 =C2=A0=C2=A0Ph. D. candidate

=20 =20 =C2=A0T=C2=A0+ 82-2-3290-3639
=20 =20 =C2=A0F=C2=A0+ 82-2-922-6341
=20 =20 =C2=A0E=C2=A0shyoo@os.korea.ac.kr
=20 =C2=A0
=20 = Home Page=C2=A0|=C2=A0=20 Blog=C2=A0|=C2=A0=20 OSVirtual=20
=C2=A0 =C2=A0OSLab.=C2=A0=E2=80=A2=20 Korea Univ. =E2=80=A2=20 Seoul=C2=A0=C2=A0=E2=80=A2= =20 South Korea=20

2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E= =91=EC=84=B1:

Hi,

Please inform the status of Xen-ARM for Cortex= -A8 CPU's on FME from ARM.

These links here
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualizatio= n_Extensions
&
http://wiki.xen.org/wiki/Xen_= ARMv7_with_Virtualization_Extensions/FastModels

give information about the dom0 running on FME= .

Though Xen-ARM is avai= lable for Cortex-A9 with KVM Virt extensions for Tegra2Harmony,

Cortex-A8 is widely us= ed, and I would like to know the status.

<= span style=3D"font-family:comic sans ms,sans-serif">So, Kindly inform, so t= hat, we could learn more about/from it.
--
=E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D

_______________________________________________
Xen-arm mailing list
= Xen-arm@lists.xe= n.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm=

--f46d044516e1cf44b704c04f0014-- --===============4825243388580487539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============4825243388580487539==-- From xen-arm-bounces@lists.xen.org Fri May 18 12:57:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 12: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 1SVMk0-0007Hb-2m; Fri, 18 May 2012 12:57:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVMjz-0007HW-13 for xen-arm@lists.xensource.com; Fri, 18 May 2012 12:57:07 +0000 Received: from [85.158.143.35:54725] by server-1.bemta-4.messagelabs.com id CC/12-00342-22746BF4; Fri, 18 May 2012 12:57:06 +0000 X-Env-Sender: seehwan.yoo@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1337345814!12071861!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_23,ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDcwNTc2MzYgKHRpbWVvdXQp\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23739 invoked from network); 18 May 2012 12:56:55 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 12:56:55 -0000 Received: by obfk16 with SMTP id k16so5216078obf.30 for ; Fri, 18 May 2012 05:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=uYkSFDoGMkUV/akgIAuG45GT/KjnCu9lNNQxRVYVuTw=; b=0mI3KXilTbMtdgqBv9lmL+0HCL+imOKIWLTkU+SSUIfGsuJc0q4wk0xPSWX41V+lz2 5MMYSXSZuJ9or70c/6mJYvx2BaIP5S9BaNnhpdUTdkXR5QNm7xuRO0a7y0KfrmUaFXmr kW73mptcOv3YQbOQrCxPvKupIVvdv5SIkkAvqR2/ieJh3yXEINC7FG11kIo13CgcYh72 LkxPVxmGt66+rBxaYdTmRvEsOhwSu3ukww0l2/5QF9qygbuQhfY2A3reeu2w0StRR3Eo udhkdv2JciKmseVvRDiRlkZ4MB5Wo71xaHyaGyLDycFiPQthS+dXctvvJe0/WF/Y3dlQ E/hw== Received: by 10.182.245.17 with SMTP id xk17mr10214840obc.66.1337345814147; Fri, 18 May 2012 05:56:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.121.105 with HTTP; Fri, 18 May 2012 05:56:33 -0700 (PDT) In-Reply-To: References: <56C765CA-598E-465B-AC3A-7BC594CEEC2B@gmail.com> From: See-Hwan Yoo Date: Fri, 18 May 2012 21:56:33 +0900 Message-ID: To: Krishna Pavan Cc: Xen Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: shyoo@os.korea.ac.kr List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4166630295911367695==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============4166630295911367695== Content-Type: multipart/alternative; boundary=14dae93b5a7e31b29604c04f160b --14dae93b5a7e31b29604c04f160b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My branch is not based on virt_extension. :< It's based on Ryu-Jaemin's branch, so it will only work with pv (not virt_extension, although the processor supports virt_extension). 2012/5/18 Krishna Pavan > Is it? > > Good & Great! > > Have you been able to run two guests on FME or on the target! > > Because, you need Virt_Extensions on for Cortex-A8, to run directly on > target right? > > > On Fri, May 18, 2012 at 5:41 PM, Seehwan Yoo wrote= : > >> Hi, >> We've been working with Xen-ARM_pv for cortex-a8. >> We've run two guest Linux. >> Our H/W platform is with s5pc100 that uses cortex-a8 core. >> >> >> * Seehwan Yoo * >> Ph. D. candidate >> >> T + 82-2-3290-3639 >> F + 82-2-922-6341 >> E shyoo@os.korea.ac.kr >> [image: logo] Home Page | >> Blog | OSVirtual >> OSLab. =E2=80=A2 Korea Univ. =E2=80=A2 Seoul =E2=80=A2 South Korea >> >> 2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E=91=EC=84=B1: >> >> Hi, >> >> Please inform the status of Xen-ARM for Cortex-A8 CPU's on FME from ARM. >> >> These links here >> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions >> & >> >> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastMo= dels >> >> give information about the dom0 running on FME. >> >> Though Xen-ARM is available for Cortex-A9 with KVM Virt extensions for >> Tegra2Harmony, >> >> Cortex-A8 is widely used, and I would like to know the status. >> >> So, Kindly inform, so that, we could learn more about/from it. >> -- >> =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D >> >> _______________________________________________ >> Xen-arm mailing list >> Xen-arm@lists.xen.org >> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm >> >> >> > > > -- > =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D > > --14dae93b5a7e31b29604c04f160b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

My branch is not based on virt_extension.=C2=A0:<

It'= s based on Ryu-Jaemin's branch, so it will only work with pv

(not virt_extension, although the processor supports virt_extension).

=C2=A0

2012/5/18 Krishna Pavan <post4pa= van@gmail.com>

Is it= ?

Good & Great!

Have you been able to run two guests on FME or= on the target!
Because, you need Virt= _Extensions on for Cortex-A8, to run directly on target right?
<= div class=3D"h5">

On Fri, May 18, 2012 at= 5:41 PM, Seehwan Yoo <seehwan.yoo@gmail.com> wrote:

Hi,=C2=A0
We'v= e been working with Xen-ARM_pv for cortex-a8.

We've run two guest Linux.=C2=A0

Our H/W platform is with s5pc100 that uses cortex-a8 core.
<= br>

=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
=C2=A0 =20 =C2=A0Seehwan Yoo
=20 =20 =C2=A0=C2=A0Ph. D. candidate

=20 =20 =C2=A0T=C2=A0+ 82-2-3290-3639
=20 =20 =C2=A0F=C2=A0+ 82-2-922-6341
=20 =20 =C2=A0E=C2=A0shyoo@os.korea.ac.kr
=20 =C2=A0
=20 = Home Page=C2=A0|=C2=A0=20 Blog=C2=A0|=C2=A0=20 OSVirtual=20
=C2=A0 =C2=A0OSLab.=C2=A0=E2=80=A2=20 Korea Univ. =E2=80=A2=20 Seoul=C2=A0=C2=A0=E2=80=A2= =20 South Korea=20

2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E= =91=EC=84=B1:

Hi,

Please inform the status of Xen-ARM for Cortex= -A8 CPU's on FME from ARM.

These links here
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualizatio= n_Extensions
&
http://wiki.xen.org/wiki/Xen_= ARMv7_with_Virtualization_Extensions/FastModels

give information about the dom0 running on FME= .

Though Xen-ARM is avai= lable for Cortex-A9 with KVM Virt extensions for Tegra2Harmony,

Cortex-A8 is widely us= ed, and I would like to know the status.

<= span style=3D"font-family:comic sans ms,sans-serif">So, Kindly inform, so t= hat, we could learn more about/from it.
--
=E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D

_______________________________________________
Xen-arm mailing list
= Xen-arm@lists.xe= n.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm=

--
=E2=9C=89 Regards :: Krishna Pavan<= /font> =E2=9C=8D=

My branch is not based on virt_extension.=C2=A0:<

It'= s based on Ryu-Jaemin's branch, so it will only work with pv

(not virt_extension, although the processor supports virt_extension).

=C2=A0

2012/5/18 Krishna Pavan <post4pa= van@gmail.com>

Is it= ?

Good & Great!

Have you been able to run two guests on FME or= on the target!
Because, you need Virt= _Extensions on for Cortex-A8, to run directly on target right?
<= div class=3D"h5">

On Fri, May 18, 2012 at= 5:41 PM, Seehwan Yoo <seehwan.yoo@gmail.com> wrote:

Hi,=C2=A0
We'v= e been working with Xen-ARM_pv for cortex-a8.

We've run two guest Linux.=C2=A0

Our H/W platform is with s5pc100 that uses cortex-a8 core.
<= br>

=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
=C2=A0 =20 =C2=A0Seehwan Yoo
=20 =20 =C2=A0=C2=A0Ph. D. candidate

=20 =20 =C2=A0T=C2=A0+ 82-2-3290-3639
=20 =20 =C2=A0F=C2=A0+ 82-2-922-6341
=20 =20 =C2=A0E=C2=A0shyoo@os.korea.ac.kr
=20 =C2=A0
=20 = Home Page=C2=A0|=C2=A0=20 Blog=C2=A0|=C2=A0=20 OSVirtual=20
=C2=A0 =C2=A0OSLab.=C2=A0=E2=80=A2=20 Korea Univ. =E2=80=A2=20 Seoul=C2=A0=C2=A0=E2=80=A2= =20 South Korea=20

2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E= =91=EC=84=B1:

Hi,

Please inform the status of Xen-ARM for Cortex= -A8 CPU's on FME from ARM.

These links here
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualizatio= n_Extensions
&
http://wiki.xen.org/wiki/Xen_= ARMv7_with_Virtualization_Extensions/FastModels

give information about the dom0 running on FME= .

Though Xen-ARM is avai= lable for Cortex-A9 with KVM Virt extensions for Tegra2Harmony,

Cortex-A8 is widely us= ed, and I would like to know the status.

<= span style=3D"font-family:comic sans ms,sans-serif">So, Kindly inform, so t= hat, we could learn more about/from it.
--
=E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D

_______________________________________________
Xen-arm mailing list
= Xen-arm@lists.xe= n.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm=

--
=E2=9C=89 Regards :: Krishna Pavan<= /font> =E2=9C=8D=

--14dae93b5a7e31b29604c04f160b-- --===============4166630295911367695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============4166630295911367695==-- From xen-arm-bounces@lists.xen.org Fri May 18 13:08:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 13:08: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 1SVMus-0007eh-1d; Fri, 18 May 2012 13:08:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVMuq-0007eR-18 for xen-arm@lists.xensource.com; Fri, 18 May 2012 13:08:20 +0000 Received: from [193.109.254.147:49857] by server-3.bemta-14.messagelabs.com id 8C/69-23274-3C946BF4; Fri, 18 May 2012 13:08:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1337346498!4285339!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5OTI1Mg==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18842 invoked from network); 18 May 2012 13:08: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; 18 May 2012 13:08:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,617,1330905600"; d="scan'208";a="12550509" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 18 May 2012 13:08: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.213.0; Fri, 18 May 2012 14:08:18 +0100 Message-ID: <1337346497.22316.114.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Krishna Pavan Date: Fri, 18 May 2012 14:08:17 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Xen , xen-devel Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Questions about the port of Xen to ARM with virt extensions are best posted to xen-devel, the xen-arm list focuses on the PV port. Adding xen-devel since it seems you are mainly asking about the w/-virt-extensions port. On Fri, 2012-05-18 at 12:38 +0100, Krishna Pavan wrote: > Please inform the status of Xen-ARM for Cortex-A8 CPU's on FME from > ARM. AFAIK no one has tried the w/-virt-extensions port on this model. The only ones which I know have been tried are Cortex-A15 model and AEM. Cortex-A8 already exists so I would be surprised if it were to be updated with virt extensions, do you have some reason to think that it will be? Cortex A15 and Cortex A7 are on our radar as upcoming processors which will have the extensions. Cortex A8 is not. > These links here > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions > & > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastModels > > give information about the dom0 running on FME. > > Though Xen-ARM is available for Cortex-A9 with KVM Virt extensions for > Tegra2Harmony, I'm confused by the mention of both Xen-ARM and KVM in this sentence. Also did you mean A8 or A9 here? > Cortex-A8 is widely used, and I would like to know the status. AFAIK these chips don't/won't support virtualisation extensions. Ian. _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Fri May 18 13:08:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 13:08: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 1SVMus-0007eh-1d; Fri, 18 May 2012 13:08:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVMuq-0007eR-18 for xen-arm@lists.xensource.com; Fri, 18 May 2012 13:08:20 +0000 Received: from [193.109.254.147:49857] by server-3.bemta-14.messagelabs.com id 8C/69-23274-3C946BF4; Fri, 18 May 2012 13:08:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1337346498!4285339!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5OTI1Mg==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18842 invoked from network); 18 May 2012 13:08: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; 18 May 2012 13:08:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,617,1330905600"; d="scan'208";a="12550509" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 18 May 2012 13:08: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.213.0; Fri, 18 May 2012 14:08:18 +0100 Message-ID: <1337346497.22316.114.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Krishna Pavan Date: Fri, 18 May 2012 14:08:17 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Xen , xen-devel Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Questions about the port of Xen to ARM with virt extensions are best posted to xen-devel, the xen-arm list focuses on the PV port. Adding xen-devel since it seems you are mainly asking about the w/-virt-extensions port. On Fri, 2012-05-18 at 12:38 +0100, Krishna Pavan wrote: > Please inform the status of Xen-ARM for Cortex-A8 CPU's on FME from > ARM. AFAIK no one has tried the w/-virt-extensions port on this model. The only ones which I know have been tried are Cortex-A15 model and AEM. Cortex-A8 already exists so I would be surprised if it were to be updated with virt extensions, do you have some reason to think that it will be? Cortex A15 and Cortex A7 are on our radar as upcoming processors which will have the extensions. Cortex A8 is not. > These links here > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions > & > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastModels > > give information about the dom0 running on FME. > > Though Xen-ARM is available for Cortex-A9 with KVM Virt extensions for > Tegra2Harmony, I'm confused by the mention of both Xen-ARM and KVM in this sentence. Also did you mean A8 or A9 here? > Cortex-A8 is widely used, and I would like to know the status. AFAIK these chips don't/won't support virtualisation extensions. Ian. _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Fri May 18 13:14:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 13: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 1SVN0e-0007zo-61; Fri, 18 May 2012 13:14:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVN0c-0007zX-S7 for xen-arm@lists.xensource.com; Fri, 18 May 2012 13:14:19 +0000 Received: from [85.158.139.83:2677] by server-5.bemta-5.messagelabs.com id C3/6B-13566-92B46BF4; Fri, 18 May 2012 13:14:17 +0000 X-Env-Sender: post4pavan@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1337346855!28563078!1 X-Originating-IP: [209.85.213.171] 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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26454 invoked from network); 18 May 2012 13:14:17 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 13:14:17 -0000 Received: by yenq11 with SMTP id q11so3488234yen.30 for ; Fri, 18 May 2012 06:14: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=wxMPVzLjGkl3oIOk13L0tOHk/kXvxBTSQpfI+UUtmGM=; b=YXvUjFlQI/E2pdCaX5VglxpJWN84SkTrbutwdgPw1JaDhY94FPvOXO0xLNcG1a5jFO UWlN8IZpve35sDQqNPXhNwzpB64bb9WJPYdiVq3TaXbUwwhfyVujRXszTMdTJgKyTsZm voHQ0q/DXk/8YcborsEiVRQTgnqrDofsdSDW9cAwWq+pDngk2/S6SsHp1/mf4nDZZg+y vrCqajCbeFbygYPJjXpgqF6m4J7Djz3UM9eysfg9B4yCsxT6YLm44cnpkmCpTJGv+wPG xh11O9s73BFKc4KH7ymp/CzLGD1zcPylWMKg2KDVvdF7wZ9O183/uEM0Lap1ORGqkQvL 8bEA== MIME-Version: 1.0 Received: by 10.50.17.134 with SMTP id o6mr482938igd.28.1337346855230; Fri, 18 May 2012 06:14:15 -0700 (PDT) Received: by 10.42.241.131 with HTTP; Fri, 18 May 2012 06:14:15 -0700 (PDT) In-Reply-To: <1337346497.22316.114.camel@zakaz.uk.xensource.com> References: <1337346497.22316.114.camel@zakaz.uk.xensource.com> Date: Fri, 18 May 2012 18:44:15 +0530 Message-ID: From: Krishna Pavan To: Ian Campbell Cc: Xen , xen-devel Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0484593237684097193==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============0484593237684097193== Content-Type: multipart/alternative; boundary=14dae93404993f5c5904c04f5428 --14dae93404993f5c5904c04f5428 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, I am interested to learn a bit about Cortex-A8 only, where, I am aware of the PV port. I have just learn from Seehwan-Yoo, through Xen-ARM that he was successful with PV port with dom 0 & dom U running successfully. With last source code release is for run of Xen-ARM with dom 0 on FME, as an enthusiast, I would like to ask the progress of Xen-ARM. --=20 =E2=9C=89 Thanks & Regards :: Krishna Pavan =E2=9C=8D --14dae93404993f5c5904c04f5428 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry,

I am interested to learn a bit about Cortex= -A8 only, where, I am aware of the PV port.

I have just learn from S= eehwan-Yoo, through Xen-ARM that he was successful with PV port with dom 0 = & dom U running successfully.

With last source code release is for run of Xen-ARM with dom 0 on FME,= =20 as an enthusiast, I would like to ask the progress of Xen-ARM.

--

=E2=9C=89 Thanks & Regards :: Krishna= Pavan = =E2=9C=8D

--14dae93404993f5c5904c04f5428-- --===============0484593237684097193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============0484593237684097193==-- From xen-arm-bounces@lists.xen.org Fri May 18 13:17:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 13:17: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 1SVN45-00086U-WC; Fri, 18 May 2012 13:17:53 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVN44-000862-Gr for xen-arm@lists.xensource.com; Fri, 18 May 2012 13:17:52 +0000 Received: from [193.109.254.147:22035] by server-9.bemta-14.messagelabs.com id 78/76-05787-FFB46BF4; Fri, 18 May 2012 13:17:51 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1337347071!9971144!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5OTI1Mg==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2315 invoked from network); 18 May 2012 13:17:51 -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 May 2012 13:17:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,617,1330905600"; d="scan'208";a="12550718" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 18 May 2012 13:17: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.213.0; Fri, 18 May 2012 14:17:51 +0100 Message-ID: <1337347069.22316.115.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Krishna Pavan Date: Fri, 18 May 2012 14:17:49 +0100 In-Reply-To: References: <1337346497.22316.114.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Xen , xen-devel Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Fri, 2012-05-18 at 14:14 +0100, Krishna Pavan wrote: > Sorry, > > I am interested to learn a bit about Cortex-A8 only, where, I am aware > of the PV port. OK. The links you provided were all about the other port, which was confusing. Ian. _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Fri May 18 13:17:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 13:17: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 1SVN45-00086U-WC; Fri, 18 May 2012 13:17:53 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVN44-000862-Gr for xen-arm@lists.xensource.com; Fri, 18 May 2012 13:17:52 +0000 Received: from [193.109.254.147:22035] by server-9.bemta-14.messagelabs.com id 78/76-05787-FFB46BF4; Fri, 18 May 2012 13:17:51 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1337347071!9971144!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5OTI1Mg==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2315 invoked from network); 18 May 2012 13:17:51 -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 May 2012 13:17:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,617,1330905600"; d="scan'208";a="12550718" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 18 May 2012 13:17: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.213.0; Fri, 18 May 2012 14:17:51 +0100 Message-ID: <1337347069.22316.115.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Krishna Pavan Date: Fri, 18 May 2012 14:17:49 +0100 In-Reply-To: References: <1337346497.22316.114.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Xen , xen-devel Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Fri, 2012-05-18 at 14:14 +0100, Krishna Pavan wrote: > Sorry, > > I am interested to learn a bit about Cortex-A8 only, where, I am aware > of the PV port. OK. The links you provided were all about the other port, which was confusing. Ian. _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Fri May 18 13:25:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 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 1SVNBE-0008TE-Vr; Fri, 18 May 2012 13: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 1SVNBE-0008T1-AF for xen-arm@lists.xensource.com; Fri, 18 May 2012 13:25:16 +0000 Received: from [85.158.143.99:63509] by server-3.bemta-4.messagelabs.com id 13/9B-05853-ABD46BF4; Fri, 18 May 2012 13:25:14 +0000 X-Env-Sender: josep.subirats@bsc.es X-Msg-Ref: server-2.tower-216.messagelabs.com!1337347512!23336666!1 X-Originating-IP: [84.88.52.34] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28201 invoked from network); 18 May 2012 13:25:12 -0000 Received: from mao.bsc.es (HELO opsmail01.bsc.es) (84.88.52.34) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 May 2012 13:25:12 -0000 Received: from localhost (localhost [127.0.0.1]) by opsmail01.bsc.es (Postfix) with ESMTP id A7B5C4C7C5; Fri, 18 May 2012 15:25:10 +0200 (CEST) Received: from opsmail01.bsc.es ([127.0.0.1]) by localhost (opswc01.bsc.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10920-08-2; Fri, 18 May 2012 15:25:10 +0200 (CEST) Received: from opswc01.bsc.es (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opsmail01.bsc.es (Postfix) with ESMTPS id D937945B87; Fri, 18 May 2012 15:25:09 +0200 (CEST) Received: (from filter@localhost) by opswc01.bsc.es (8.13.6/8.13.6/Submit) id q4IDP9xC017652; Fri, 18 May 2012 15:25:09 +0200 Received: from [192.168.1.12] (175.pool85-58-80.dynamic.orange.es [85.58.80.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opsmail01.bsc.es (Postfix) with ESMTPSA id 764AB45A96; Fri, 18 May 2012 15:25:09 +0200 (CEST) Message-ID: <4FB64DB5.9090405@bsc.es> Date: Fri, 18 May 2012 15:25:09 +0200 From: Josep Subirats User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ian Campbell References: <1337346497.22316.114.camel@zakaz.uk.xensource.com> <1337347069.22316.115.camel@zakaz.uk.xensource.com> In-Reply-To: <1337347069.22316.115.camel@zakaz.uk.xensource.com> X-Copyrighted-Material: Please visit http://www.bsc.es/disclaimer.htm X-Virus-Scanned: amavisd-new at bsc.es Cc: xen-devel , Xen Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Hello, My apologies for going into this conversation. :) My situation is that I have a Tegra 250 Harmony Board (Cortex A-9) and I'd like to run Xen-ARM on top of it. From what I read, this is possible, and although I have read and followed several tutorials on how to compile it, I'm still unable to achieve it. Could you point me to the appropiate tutorial or forum post for my board? I'd be really grateful. Best regards, Josep Subirats On 05/18/2012 03:17 PM, Ian Campbell wrote: > On Fri, 2012-05-18 at 14:14 +0100, Krishna Pavan wrote: >> Sorry, >> >> I am interested to learn a bit about Cortex-A8 only, where, I am aware >> of the PV port. > OK. The links you provided were all about the other port, which was > confusing. > > Ian. > > > > > _______________________________________________ > Xen-arm mailing list > Xen-arm@lists.xen.org > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received. http://www.bsc.es/disclaimer _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Fri May 18 13:25:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 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 1SVNBE-0008TE-Vr; Fri, 18 May 2012 13: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 1SVNBE-0008T1-AF for xen-arm@lists.xensource.com; Fri, 18 May 2012 13:25:16 +0000 Received: from [85.158.143.99:63509] by server-3.bemta-4.messagelabs.com id 13/9B-05853-ABD46BF4; Fri, 18 May 2012 13:25:14 +0000 X-Env-Sender: josep.subirats@bsc.es X-Msg-Ref: server-2.tower-216.messagelabs.com!1337347512!23336666!1 X-Originating-IP: [84.88.52.34] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28201 invoked from network); 18 May 2012 13:25:12 -0000 Received: from mao.bsc.es (HELO opsmail01.bsc.es) (84.88.52.34) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 May 2012 13:25:12 -0000 Received: from localhost (localhost [127.0.0.1]) by opsmail01.bsc.es (Postfix) with ESMTP id A7B5C4C7C5; Fri, 18 May 2012 15:25:10 +0200 (CEST) Received: from opsmail01.bsc.es ([127.0.0.1]) by localhost (opswc01.bsc.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10920-08-2; Fri, 18 May 2012 15:25:10 +0200 (CEST) Received: from opswc01.bsc.es (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opsmail01.bsc.es (Postfix) with ESMTPS id D937945B87; Fri, 18 May 2012 15:25:09 +0200 (CEST) Received: (from filter@localhost) by opswc01.bsc.es (8.13.6/8.13.6/Submit) id q4IDP9xC017652; Fri, 18 May 2012 15:25:09 +0200 Received: from [192.168.1.12] (175.pool85-58-80.dynamic.orange.es [85.58.80.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opsmail01.bsc.es (Postfix) with ESMTPSA id 764AB45A96; Fri, 18 May 2012 15:25:09 +0200 (CEST) Message-ID: <4FB64DB5.9090405@bsc.es> Date: Fri, 18 May 2012 15:25:09 +0200 From: Josep Subirats User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ian Campbell References: <1337346497.22316.114.camel@zakaz.uk.xensource.com> <1337347069.22316.115.camel@zakaz.uk.xensource.com> In-Reply-To: <1337347069.22316.115.camel@zakaz.uk.xensource.com> X-Copyrighted-Material: Please visit http://www.bsc.es/disclaimer.htm X-Virus-Scanned: amavisd-new at bsc.es Cc: xen-devel , Xen Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Hello, My apologies for going into this conversation. :) My situation is that I have a Tegra 250 Harmony Board (Cortex A-9) and I'd like to run Xen-ARM on top of it. From what I read, this is possible, and although I have read and followed several tutorials on how to compile it, I'm still unable to achieve it. Could you point me to the appropiate tutorial or forum post for my board? I'd be really grateful. Best regards, Josep Subirats On 05/18/2012 03:17 PM, Ian Campbell wrote: > On Fri, 2012-05-18 at 14:14 +0100, Krishna Pavan wrote: >> Sorry, >> >> I am interested to learn a bit about Cortex-A8 only, where, I am aware >> of the PV port. > OK. The links you provided were all about the other port, which was > confusing. > > Ian. > > > > > _______________________________________________ > Xen-arm mailing list > Xen-arm@lists.xen.org > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received. http://www.bsc.es/disclaimer _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Fri May 18 13:36:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 13: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 1SVNLm-0000Xi-2G; Fri, 18 May 2012 13:36:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVNLk-0000Xc-Cy for xen-arm@lists.xensource.com; Fri, 18 May 2012 13:36:08 +0000 Received: from [85.158.143.99:64689] by server-1.bemta-4.messagelabs.com id E6/9D-00342-74056BF4; Fri, 18 May 2012 13:36:07 +0000 X-Env-Sender: post4pavan@gmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1337348164!19023265!1 X-Originating-IP: [209.85.213.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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20726 invoked from network); 18 May 2012 13:36:06 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 13:36:06 -0000 Received: by yhkk6 with SMTP id k6so3581854yhk.30 for ; Fri, 18 May 2012 06:36: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=ljPsbmoJb2z8Ue5f7aeherrKeGH+OSxw7UfOs+HSeJA=; b=EBNjIabyo6fb6FHbPeSkFRn9OZ4Wh4faYh1YZ1CaXB5ImKjobJAzVMGp+Ama7S+0kc BdeS3WslzEktv9OV8/ucE1Ujxjbs51+tACtkKWoxlkXJxauzZBGrnI8Iww2WYNdOke7o tauy2EZCCbkoNJtdBlS6qJnea760fdNzg9IUVnpwCYsKyPJ/yD+pbrm9f6MKTqxCMAvF k+GSuaPJyhqtfs46cDhJ648CDdlJdB4VzuxEaMYZcnkEXpapEcQWxd5frgJf/j06lR8N ntSmjblHZutyg8AxWLgXCvvUaR9TnvCKEIzdjSUoq14HfOxYm2BqcXVDIF9Ij+HHD8qi OiHg== MIME-Version: 1.0 Received: by 10.50.237.34 with SMTP id uz2mr581026igc.19.1337348164198; Fri, 18 May 2012 06:36:04 -0700 (PDT) Received: by 10.42.241.131 with HTTP; Fri, 18 May 2012 06:36:04 -0700 (PDT) In-Reply-To: <0LZ100H9XVCY7HD0@mailout4.samsung.com> References: <0LZ100H9XVCY7HD0@mailout4.samsung.com> Date: Fri, 18 May 2012 19:06:04 +0530 Message-ID: From: Krishna Pavan To: xen-arm@lists.xensource.com Subject: Re: [XenARM] Para-virtualized linux kernel release for the Tegra2 harmony board. X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6404418911248868108==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============6404418911248868108== Content-Type: multipart/alternative; boundary=f46d04479511449f7a04c04fa23e --f46d04479511449f7a04c04fa23e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Following are some of the instructions given by Jae-Min-Ryu. However, you need to find and place proper links with in the linux-xen source code. There have been some issues with the mode bits for some files in the linux-xen source code. Hope, these issues, which I have found [others have found many and you may probably need to check previous threads], when I worked on those particular source codes, will help you. It would be better to post a new mail, if it's not found in google search, rather than top-posting, as it may disturb the flow, if some one browses the lists next time. Regards :: Krishna Pavan On Wed, Feb 8, 2012 at 6:42 AM, Jae-Min Ryu wrote: > We have release a reference code for a para-virtualized linux kernel. > > > You will find it on "git://xenbits.xen.org/people/jm77ryu/linux-xen.git" > > In case of xen-arm source, please visit to "git:// > xenbits.xen.org/people/jm77ryu/xen-arm.git" > > > - Build Instructions: - > > 1. extract root filesytem contents as following(This requires the root > privilege) > sudo tar -xvpf rootfs_dom0.tar.bz2 > > 2. cp config_dom0 .config > > 3. make ARCH=3Darm > > ** Turn on target board, and download the xen-arm image(xen) and the > kernel image(vmlinux.out0). > ** download addresse is : > ***** xen-arm : 0x8000 > ***** guest kernel images : 0x1e800000 > > - booting domu - > > ** To boot domu (the rootfilesystem of dom0 already has prebuilt domu > kernel images, see images directory.) > # smd start <- start lightweight > # vm create /etc/xen/dom1 > # xenconsole 1 <=3D This command switch console to dom 1. > > * For domu build, use config_domu configuration file. > * Don't forget to copy the vmlinux.out1 to rootfs_dom0/images directory > after domu kernel build. > > --=20 =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D --f46d04479511449f7a04c04fa23e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

Following are some of the instructions given by Jae-Min-= Ryu.
However, you need to find and place proper links with in the linux-= xen source code.

There have been some issues with the mode bits for some files in the li= nux-xen source code.

Hope, these issues, which I have found <= font style=3D"font-family:comic sans ms,sans-serif" size=3D"2">[others have found many and you may probably need to check previous = threads], when I worked on those particular source codes, will help = you.

It would be better to post a new mail, if it's not found in google = search, rather than top-posting, as it may disturb the flow, if some one br= owses the lists next time.

Regards :: Krishna Pavan

On Wed, Feb 8, 2012 at 6:42 AM, Jae-Min Ryu wrote:

We have release a reference code for a para-virtualized linux kernel.

You will find it on "git://xenbits.xen.org/people/jm77ry= u/linux-xen.git"

In case of xen-arm source, please visit to= "git://xenbits.xen.org/people/jm77ryu/xen-arm.git"

- Build Instructions: -

1. extract root filesytem contents a= s following(This requires the root privilege)
=C2=A0=C2=A0=C2=A0=C2=A0su= do tar -xvpf rootfs_dom0.tar.bz2

2. cp config_dom0 .config

3.= make ARCH=3Darm

** Turn on target board, and download the xen-arm image(xen) and the ke= rnel image(vmlinux.out0).
** download addresse is :
***** xen-arm : 0= x8000
***** guest kernel images : 0x1e800000

- booting domu -

** To boot domu (the rootfilesystem of dom0 already has prebuilt domu k= ernel images, see images directory.)
# smd start=C2=A0=C2=A0=C2=A0=C2=A0= <- start lightweight
# vm create /etc/xen/dom1
# xenconsole 1=C2= =A0=C2=A0=C2=A0=C2=A0<=3D This command switch console to dom 1.

* For domu build, use config_domu configuration file.
* Don't fo= rget to copy the vmlinux.out1 to rootfs_dom0/images directory after domu ke= rnel build.

=E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D

--f46d04479511449f7a04c04fa23e-- --===============6404418911248868108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============6404418911248868108==-- From xen-arm-bounces@lists.xen.org Fri May 18 13:36:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 13: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 1SVNLm-0000Xi-2G; Fri, 18 May 2012 13:36:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVNLk-0000Xc-Cy for xen-arm@lists.xensource.com; Fri, 18 May 2012 13:36:08 +0000 Received: from [85.158.143.99:64689] by server-1.bemta-4.messagelabs.com id E6/9D-00342-74056BF4; Fri, 18 May 2012 13:36:07 +0000 X-Env-Sender: post4pavan@gmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1337348164!19023265!1 X-Originating-IP: [209.85.213.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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20726 invoked from network); 18 May 2012 13:36:06 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 13:36:06 -0000 Received: by yhkk6 with SMTP id k6so3581854yhk.30 for ; Fri, 18 May 2012 06:36: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=ljPsbmoJb2z8Ue5f7aeherrKeGH+OSxw7UfOs+HSeJA=; b=EBNjIabyo6fb6FHbPeSkFRn9OZ4Wh4faYh1YZ1CaXB5ImKjobJAzVMGp+Ama7S+0kc BdeS3WslzEktv9OV8/ucE1Ujxjbs51+tACtkKWoxlkXJxauzZBGrnI8Iww2WYNdOke7o tauy2EZCCbkoNJtdBlS6qJnea760fdNzg9IUVnpwCYsKyPJ/yD+pbrm9f6MKTqxCMAvF k+GSuaPJyhqtfs46cDhJ648CDdlJdB4VzuxEaMYZcnkEXpapEcQWxd5frgJf/j06lR8N ntSmjblHZutyg8AxWLgXCvvUaR9TnvCKEIzdjSUoq14HfOxYm2BqcXVDIF9Ij+HHD8qi OiHg== MIME-Version: 1.0 Received: by 10.50.237.34 with SMTP id uz2mr581026igc.19.1337348164198; Fri, 18 May 2012 06:36:04 -0700 (PDT) Received: by 10.42.241.131 with HTTP; Fri, 18 May 2012 06:36:04 -0700 (PDT) In-Reply-To: <0LZ100H9XVCY7HD0@mailout4.samsung.com> References: <0LZ100H9XVCY7HD0@mailout4.samsung.com> Date: Fri, 18 May 2012 19:06:04 +0530 Message-ID: From: Krishna Pavan To: xen-arm@lists.xensource.com Subject: Re: [XenARM] Para-virtualized linux kernel release for the Tegra2 harmony board. X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6404418911248868108==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============6404418911248868108== Content-Type: multipart/alternative; boundary=f46d04479511449f7a04c04fa23e --f46d04479511449f7a04c04fa23e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Following are some of the instructions given by Jae-Min-Ryu. However, you need to find and place proper links with in the linux-xen source code. There have been some issues with the mode bits for some files in the linux-xen source code. Hope, these issues, which I have found [others have found many and you may probably need to check previous threads], when I worked on those particular source codes, will help you. It would be better to post a new mail, if it's not found in google search, rather than top-posting, as it may disturb the flow, if some one browses the lists next time. Regards :: Krishna Pavan On Wed, Feb 8, 2012 at 6:42 AM, Jae-Min Ryu wrote: > We have release a reference code for a para-virtualized linux kernel. > > > You will find it on "git://xenbits.xen.org/people/jm77ryu/linux-xen.git" > > In case of xen-arm source, please visit to "git:// > xenbits.xen.org/people/jm77ryu/xen-arm.git" > > > - Build Instructions: - > > 1. extract root filesytem contents as following(This requires the root > privilege) > sudo tar -xvpf rootfs_dom0.tar.bz2 > > 2. cp config_dom0 .config > > 3. make ARCH=3Darm > > ** Turn on target board, and download the xen-arm image(xen) and the > kernel image(vmlinux.out0). > ** download addresse is : > ***** xen-arm : 0x8000 > ***** guest kernel images : 0x1e800000 > > - booting domu - > > ** To boot domu (the rootfilesystem of dom0 already has prebuilt domu > kernel images, see images directory.) > # smd start <- start lightweight > # vm create /etc/xen/dom1 > # xenconsole 1 <=3D This command switch console to dom 1. > > * For domu build, use config_domu configuration file. > * Don't forget to copy the vmlinux.out1 to rootfs_dom0/images directory > after domu kernel build. > > --=20 =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D --f46d04479511449f7a04c04fa23e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 8, 2012 at 6:42 AM, Jae-Min Ryu wrote:

We have release a reference code for a para-virtualized linux kernel.

You will find it on "git://xenbits.xen.org/people/jm77ry= u/linux-xen.git"

In case of xen-arm source, please visit to= "git://xenbits.xen.org/people/jm77ryu/xen-arm.git"

- Build Instructions: -

1. extract root filesytem contents a= s following(This requires the root privilege)
=C2=A0=C2=A0=C2=A0=C2=A0su= do tar -xvpf rootfs_dom0.tar.bz2

2. cp config_dom0 .config

3.= make ARCH=3Darm

** Turn on target board, and download the xen-arm image(xen) and the ke= rnel image(vmlinux.out0).
** download addresse is :
***** xen-arm : 0= x8000
***** guest kernel images : 0x1e800000

- booting domu -

** To boot domu (the rootfilesystem of dom0 already has prebuilt domu k= ernel images, see images directory.)
# smd start=C2=A0=C2=A0=C2=A0=C2=A0= <- start lightweight
# vm create /etc/xen/dom1
# xenconsole 1=C2= =A0=C2=A0=C2=A0=C2=A0<=3D This command switch console to dom 1.

* For domu build, use config_domu configuration file.
* Don't fo= rget to copy the vmlinux.out1 to rootfs_dom0/images directory after domu ke= rnel build.

=E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D

--f46d04479511449f7a04c04fa23e-- --===============6404418911248868108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============6404418911248868108==-- From xen-arm-bounces@lists.xen.org Fri May 18 15:44:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 May 2012 15: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 1SVPLN-0001c4-Nr; Fri, 18 May 2012 15:43:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVPLM-0001bz-HH for xen-arm@lists.xensource.com; Fri, 18 May 2012 15:43:52 +0000 Received: from [85.158.143.35:65243] by server-3.bemta-4.messagelabs.com id 16/01-05853-73E66BF4; Fri, 18 May 2012 15:43:51 +0000 X-Env-Sender: seehwan.yoo@gmail.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1337355829!16179552!1 X-Originating-IP: [209.85.216.48] 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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27187 invoked from network); 18 May 2012 15:43:50 -0000 Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 15:43:50 -0000 Received: by qady23 with SMTP id y23so364717qad.7 for ; Fri, 18 May 2012 08:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=dPq2vSrTCLle4bwvU6mZDmeUalW1tMYJIj0NCfCSXiM=; b=Zj63E50DvQb/lVtWZRVxlp/pjtY9e59NAsd6r8gKwnOavQEOQ+aqUVoXHmcOJfzvu4 mIqT4T0e5JZo8bQBSy2QHEpPNcL7ItzylB5Qh6eL04TycrAXwy7+daLfDpJzqM07iqsR LEaC/qPnOywuztOQ/+XNRMBVYo2jqfIYVybkLkXTG5e3W5IE+n+qfVfjUFQkMiqzKsAS PeuoArPaUECacExJhonTMwV+LrIRqN1eKZfvdwZYDK19GUSxdgrUaSMNY+KzuS8jSvAW 6JlaTw2THPiWx8NDyZp6CCE8Snw/Ev+mXeUDYFjgN5P0LaCH3JuZsv8llSMIFv1r4tLL l4yg== Received: by 10.60.14.169 with SMTP id q9mr11027420oec.19.1337355829153; Fri, 18 May 2012 08:43:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.121.105 with HTTP; Fri, 18 May 2012 08:43:28 -0700 (PDT) In-Reply-To: <4FB64DB5.9090405@bsc.es> References: <1337346497.22316.114.camel@zakaz.uk.xensource.com> <1337347069.22316.115.camel@zakaz.uk.xensource.com> <4FB64DB5.9090405@bsc.es> From: See-Hwan Yoo Date: Sat, 19 May 2012 00:43:28 +0900 Message-ID: To: Josep Subirats Cc: Xen Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: shyoo@os.korea.ac.kr List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2650098226814114602==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============2650098226814114602== Content-Type: multipart/alternative; boundary=e89a8fb1ee0e228f1404c0516bfc --e89a8fb1ee0e228f1404c0516bfc Content-Type: text/plain; charset=ISO-8859-1 First, run u-boot with your board. Then, put your xen-bin and linux image in a DRAM Finally, run xen-arm. To do these, you need to have a proper image (xen-arm, xen-linux), you need to be aware of memory map, and you need to run u-boot with your board. BTW. I've double checked the spec of cortex-a8. It does not support virt_extension despite it is armv7-a. So, all cortex-a8 rel. things are only available w/ pv branch. 2012/5/18 Josep Subirats > Hello, > > My apologies for going into this conversation. :) My situation is that I > have a Tegra 250 Harmony Board (Cortex A-9) and I'd like to run Xen-ARM on > top of it. From what I read, this is possible, and although I have read and > followed several tutorials on how to compile it, I'm still unable to > achieve it. Could you point me to the appropiate tutorial or forum post for > my board? I'd be really grateful. > > Best regards, > > Josep Subirats > > > On 05/18/2012 03:17 PM, Ian Campbell wrote: > >> On Fri, 2012-05-18 at 14:14 +0100, Krishna Pavan wrote: >> >>> Sorry, >>> >>> I am interested to learn a bit about Cortex-A8 only, where, I am aware >>> of the PV port. >>> >> OK. The links you provided were all about the other port, which was >> confusing. >> >> Ian. >> >> >> >> >> ______________________________**_________________ >> Xen-arm mailing list >> Xen-arm@lists.xen.org >> http://lists.xen.org/cgi-bin/**mailman/listinfo/xen-arm >> > > WARNING / LEGAL TEXT: This message is intended only for the use of the > individual or entity to which it is addressed and may contain > information which is privileged, confidential, proprietary, or exempt > from disclosure under applicable law. If you are not the intended > recipient or the person responsible for delivering the message to the > intended recipient, you are strictly prohibited from disclosing, > distributing, copying, or in any way using this message. If you have > received this communication in error, please notify the sender and > destroy and delete any copies you may have received. > > http://www.bsc.es/disclaimer > > > ______________________________**_________________ > Xen-arm mailing list > Xen-arm@lists.xen.org > http://lists.xen.org/cgi-bin/**mailman/listinfo/xen-arm > --e89a8fb1ee0e228f1404c0516bfc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First, run u-boot with your board.

Then, put your xen-bin and linux ima= ge in a DRAM=A0

Finally, run xen-arm.

To= do these,=A0

you need to have a proper image (xen-arm, xen-linux= ), you need to be aware of memory map, and you need to run u-boot with your= board.=A0

BTW. I've double checked the spec of cortex-a8. It does = not support virt_extension despite it is armv7-a.=A0

So, all cort= ex-a8 rel. things are only available w/ pv branch.=A0

2012/5/18 Josep Subirats <<= a href=3D"mailto:josep.subirats@bsc.es" target=3D"_blank">josep.subirats@bs= c.es>

Hello,

My apologies for going into this conversation. :) My situation is that I ha= ve a Tegra 250 Harmony Board (Cortex A-9) and I'd like to run Xen-ARM o= n top of it. From what I read, this is possible, and although I have read a= nd followed several tutorials on how to compile it, I'm still unable to= achieve it. Could you point me to the appropiate tutorial or forum post fo= r my board? I'd be really grateful.

Best regards,

Josep Subirats

On 05/18/2012 03:17 PM, Ian Campbell wrote:

On Fri, 2012-05-18 at 14:14 +0100, Krishna Pavan wrote:

Sorry,

I am interested to learn a bit about Cortex-A8 only, where, I am aware
of the PV port.

OK. The links you provided were all about the other port, which was
confusing.

Ian.

_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xe= n.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

http://www.bsc.e= s/disclaimer

_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xe= n.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

Then, put your xen-bin and linux ima= ge in a DRAM=A0

Finally, run xen-arm.

To= do these,=A0

you need to have a proper image (xen-arm, xen-linux= ), you need to be aware of memory map, and you need to run u-boot with your= board.=A0

BTW. I've double checked the spec of cortex-a8. It does = not support virt_extension despite it is armv7-a.=A0

So, all cort= ex-a8 rel. things are only available w/ pv branch.=A0

2012/5/18 Josep Subirats <<= a href=3D"mailto:josep.subirats@bsc.es" target=3D"_blank">josep.subirats@bs= c.es>

Hello,

My apologies for going into this conversation. :) My situation is that I ha= ve a Tegra 250 Harmony Board (Cortex A-9) and I'd like to run Xen-ARM o= n top of it. From what I read, this is possible, and although I have read a= nd followed several tutorials on how to compile it, I'm still unable to= achieve it. Could you point me to the appropiate tutorial or forum post fo= r my board? I'd be really grateful.

Best regards,

Josep Subirats

On 05/18/2012 03:17 PM, Ian Campbell wrote:

On Fri, 2012-05-18 at 14:14 +0100, Krishna Pavan wrote:

Sorry,

I am interested to learn a bit about Cortex-A8 only, where, I am aware
of the PV port.

OK. The links you provided were all about the other port, which was
confusing.

Ian.

_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xe= n.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

http://www.bsc.e= s/disclaimer

_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xe= n.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

--e89a8fb1ee0e228f1404c0516bfc-- --===============2650098226814114602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============2650098226814114602==-- From xen-arm-bounces@lists.xen.org Mon May 21 09:55:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 May 2012 09:55: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 1SWPKN-0000Y9-CV; Mon, 21 May 2012 09:54:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SWPKL-0000Xd-D2 for xen-arm@lists.xen.org; Mon, 21 May 2012 09:54:57 +0000 Received: from [85.158.143.35:27499] by server-2.bemta-4.messagelabs.com id F4/7D-12211-0F01ABF4; Mon, 21 May 2012 09:54:56 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1337594094!10637707!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24122 invoked from network); 21 May 2012 09:54:55 -0000 Received: from mail-lpp01m010-f45.google.com (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 May 2012 09:54:55 -0000 Received: by lahc1 with SMTP id c1so4171387lah.32 for ; Mon, 21 May 2012 02:54: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:content-transfer-encoding; bh=XcloucNflffoiZTsZSYDAeWAkCrO/Q/+EEKnAb1UgDI=; b=BXkcfQ+l4iSo+3OhEETXV4k4AZbISv7+SvoksPPezX3aEQYvr4Y2LoXYOsYAjrFRso /xgUhffZHz138+BKU8Xmo9bx8NOgLDUOIYVixNyz0ubWXME7Jkd5ZCoEqRxGWaWV0xmj brrGZcDbLFaa8cfLur+3Z08YQRm9wG/OZ1Ri1C8tTDoG9OmTRb5dLRjAYAqvC9+7EaSY d4XxGFz2eZxV8x2Uyt5oRoqDV3F1jl2s6UzDqAa0a6ivD8YcpmTyCP4wD7r43riw3eV4 l6cw42doYIJvhD/hgPZuC7vyAanIJiIeM1khkvE+Vp7hq280IOCdvfF+/QYO+mK5lNVx LjZw== Received: by 10.112.49.68 with SMTP id s4mr8455050lbn.27.1337594093826; Mon, 21 May 2012 02:54:53 -0700 (PDT) Received: from [172.16.25.10] (b0fb6af0.bb.sky.com. [176.251.106.240]) by mx.google.com with ESMTPS id xx8sm1738020lab.10.2012.05.21.02.54.51 (version=SSLv3 cipher=OTHER); Mon, 21 May 2012 02:54:52 -0700 (PDT) Message-ID: <4FBA10EA.5030904@xen.org> Date: Mon, 21 May 2012 10:54:50 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-arm@lists.xen.org, "xen-api@lists.xen.org" Subject: [XenARM] [Announce] Version 1.2 of project governance has been approved X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Hi, everybody. Last week's vote on changes proposed in http://xen.org/projects/governance_v1_2.html concluded with 9 votes for the proposal, 0 votes abstaining and 0 votes against. This means the new version of the process will come in effect as of today. Best Regards Lars _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Mon May 21 09:55:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 May 2012 09:55: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 1SWPKN-0000Y9-CV; Mon, 21 May 2012 09:54:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SWPKL-0000Xd-D2 for xen-arm@lists.xen.org; Mon, 21 May 2012 09:54:57 +0000 Received: from [85.158.143.35:27499] by server-2.bemta-4.messagelabs.com id F4/7D-12211-0F01ABF4; Mon, 21 May 2012 09:54:56 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1337594094!10637707!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24122 invoked from network); 21 May 2012 09:54:55 -0000 Received: from mail-lpp01m010-f45.google.com (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 May 2012 09:54:55 -0000 Received: by lahc1 with SMTP id c1so4171387lah.32 for ; Mon, 21 May 2012 02:54: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:content-transfer-encoding; bh=XcloucNflffoiZTsZSYDAeWAkCrO/Q/+EEKnAb1UgDI=; b=BXkcfQ+l4iSo+3OhEETXV4k4AZbISv7+SvoksPPezX3aEQYvr4Y2LoXYOsYAjrFRso /xgUhffZHz138+BKU8Xmo9bx8NOgLDUOIYVixNyz0ubWXME7Jkd5ZCoEqRxGWaWV0xmj brrGZcDbLFaa8cfLur+3Z08YQRm9wG/OZ1Ri1C8tTDoG9OmTRb5dLRjAYAqvC9+7EaSY d4XxGFz2eZxV8x2Uyt5oRoqDV3F1jl2s6UzDqAa0a6ivD8YcpmTyCP4wD7r43riw3eV4 l6cw42doYIJvhD/hgPZuC7vyAanIJiIeM1khkvE+Vp7hq280IOCdvfF+/QYO+mK5lNVx LjZw== Received: by 10.112.49.68 with SMTP id s4mr8455050lbn.27.1337594093826; Mon, 21 May 2012 02:54:53 -0700 (PDT) Received: from [172.16.25.10] (b0fb6af0.bb.sky.com. [176.251.106.240]) by mx.google.com with ESMTPS id xx8sm1738020lab.10.2012.05.21.02.54.51 (version=SSLv3 cipher=OTHER); Mon, 21 May 2012 02:54:52 -0700 (PDT) Message-ID: <4FBA10EA.5030904@xen.org> Date: Mon, 21 May 2012 10:54:50 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-arm@lists.xen.org, "xen-api@lists.xen.org" Subject: [XenARM] [Announce] Version 1.2 of project governance has been approved X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Hi, everybody. Last week's vote on changes proposed in http://xen.org/projects/governance_v1_2.html concluded with 9 votes for the proposal, 0 votes abstaining and 0 votes against. This means the new version of the process will come in effect as of today. Best Regards Lars _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWy-0006jI-Ko; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQge8-0005cE-J8 for xen-arm@lists.xen.org; Sat, 05 May 2012 15:11:44 +0000 Received: from [85.158.143.35:30950] by server-2.bemta-4.messagelabs.com id 93/1D-17550-F2345AF4; Sat, 05 May 2012 15:11:43 +0000 X-Env-Sender: marc.zyngier@arm.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336230702!4448659!1 X-Originating-IP: [91.220.42.44] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDIxNzM4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6129 invoked from network); 5 May 2012 15:11:42 -0000 Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by server-9.tower-21.messagelabs.com with SMTP; 5 May 2012 15:11:42 -0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Sat, 05 May 2012 16:11:41 +0100 Received: from taxman.wild-wind.fr.eu.org ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 May 2012 16:13:12 +0100 Date: Sat, 5 May 2012 16:11:28 +0100 From: Marc Zyngier To: Anup Patel Message-ID: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> In-Reply-To: References:

Organization: ARM Ltd X-Mailer: Claws Mail 3.8.0 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-OriginalArrivalTime: 05 May 2012 15:16:12.0592 (UTC) FILETIME=[01D61B00:01CD2AD2] X-MC-Unique: 112050516144100201 X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Sat, 5 May 2012 15:31:36 +0100 Anup Patel wrote: > Hi PMM, > > Also in my-view even if we have in-kernel emulation of irqchip and timer still Xvisor ARM will be performing better than KVM ARM because amount of code path traversed in KVM ARM will always be more. > > (Please note my-view about in-kernel emulation is totally based on code flow comparison of Xvisor ARM emulation and possible KVM ARM in-kernel emulation) > Sweet. Can I borrow your crystal ball? M. > On Sat, May 5, 2012 at 7:54 PM, Anup Patel > wrote: > Hi PMM, > > I agree we cannot predict real world performance based on performance on ARM fast models but if system A is performing better than system B no ARM fast model or QEMU then in real world system A will perform better than system B. Of-course in real world scale of difference in performance between system A and system B will differ. > > The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. > > Regards, > --Anup > > > On Sat, May 5, 2012 at 3:36 PM, Peter Maydell > wrote: > 2012/5/5 Anup Patel >: > > This announcement is to show an apple to apple performance comparison > > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. > > I would strongly caution against trying to do any performance/timing > type tests if you're still running on the ARM Fast Model -- they are > not representative of performance characteristics on hardware > and you really can't draw any conclusions about real world > performance by timing things on a model. It's quite easy to get > into a situation where all you're measuring is "does my code happen > to do a lot of some perfectly reasonable operation which happens > to be hard and slow to implement for the model?". > > (Also, KVM for ARM is still under development and we haven't > yet made several of the obvious performance improvements like > in-kernel irqchip and timer support, so it's not really a very > useful thing to compare against yet.) > > -- PMM > > -- I'm the slime oozin' out from your TV set... _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWy-0006jI-Ko; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQge8-0005cE-J8 for xen-arm@lists.xen.org; Sat, 05 May 2012 15:11:44 +0000 Received: from [85.158.143.35:30950] by server-2.bemta-4.messagelabs.com id 93/1D-17550-F2345AF4; Sat, 05 May 2012 15:11:43 +0000 X-Env-Sender: marc.zyngier@arm.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336230702!4448659!1 X-Originating-IP: [91.220.42.44] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDIxNzM4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6129 invoked from network); 5 May 2012 15:11:42 -0000 Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by server-9.tower-21.messagelabs.com with SMTP; 5 May 2012 15:11:42 -0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Sat, 05 May 2012 16:11:41 +0100 Received: from taxman.wild-wind.fr.eu.org ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 May 2012 16:13:12 +0100 Date: Sat, 5 May 2012 16:11:28 +0100 From: Marc Zyngier To: Anup Patel Message-ID: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> In-Reply-To: References:

Organization: ARM Ltd X-Mailer: Claws Mail 3.8.0 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-OriginalArrivalTime: 05 May 2012 15:13:12.0659 (UTC) FILETIME=[96968230:01CD2AD1] X-MC-Unique: 112050516114100201 X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Sat, 5 May 2012 15:24:26 +0100 Anup Patel wrote: > Hi PMM, > > I agree we cannot predict real world performance based on performance on ARM fast models but if system A is performing better than system B no ARM fast model or QEMU then in real world system A will perform better than system B. Of-course in real world scale of difference in performance between system A and system B will differ. > You may want to re-read Peter's email, and consider that the model doesn't represent the micro-architecture. A code sequence X can be faster than a sequence Y on the model, and the opposite on real hardware. The same is equally valid on two different implementation of the same architecture (Cortex-A7 vs Cortex-A15, for example). > The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. On the Fast Model. M. > On Sat, May 5, 2012 at 3:36 PM, Peter Maydell > wrote: > 2012/5/5 Anup Patel >: > > This announcement is to show an apple to apple performance comparison > > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. > > I would strongly caution against trying to do any performance/timing > type tests if you're still running on the ARM Fast Model -- they are > not representative of performance characteristics on hardware > and you really can't draw any conclusions about real world > performance by timing things on a model. It's quite easy to get > into a situation where all you're measuring is "does my code happen > to do a lot of some perfectly reasonable operation which happens > to be hard and slow to implement for the model?". > > (Also, KVM for ARM is still under development and we haven't > yet made several of the obvious performance improvements like > in-kernel irqchip and timer support, so it's not really a very > useful thing to compare against yet.) > > -- PMM > -- I'm the slime oozin' out from your TV set... _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWz-0006l7-Uy; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUh3-0006zD-TA for xen-arm@lists.xen.org; Thu, 10 May 2012 14:50:14 +0000 Received: from [85.158.143.35:4213] by server-2.bemta-4.messagelabs.com id 9B/74-17550-5A5DBAF4; Thu, 10 May 2012 14:50:13 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336661401!11642650!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1391 invoked from network); 10 May 2012 14:50:11 -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; 10 May 2012 14:50:11 -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 q4AEnwsp007214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 14:49: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 q4AEnvsZ013647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 14:49:58 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 q4AEnvUC026464; Thu, 10 May 2012 09:49:57 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 07:49:57 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 69DC64032D; Thu, 10 May 2012 10:43:53 -0400 (EDT) Date: Thu, 10 May 2012 10:43:53 -0400 From: Konrad Rzeszutek Wilk To: Lars Kurth Message-ID: <20120510144353.GJ26152@phenom.dumpdata.com> References: <4F912F15.2030202@xen.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4F912F15.2030202@xen.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: xen-api@lists.xen.org, xen-arm@lists.xen.org, xen-users@lists.xen.org, xen-devel@lists.xen.org Subject: Re: [XenARM] [Xen-API] Xen Documentation Day : April 23rd X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Fri, Apr 20, 2012 at 10:40:37AM +0100, Lars Kurth wrote: > Hi everybody, > > we have another Xen Documentation Day come up next Monday, April 23. When is the next one? I am itching to write some new docs! _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWz-0006l7-Uy; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUh3-0006zD-TA for xen-arm@lists.xen.org; Thu, 10 May 2012 14:50:14 +0000 Received: from [85.158.143.35:4213] by server-2.bemta-4.messagelabs.com id 9B/74-17550-5A5DBAF4; Thu, 10 May 2012 14:50:13 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336661401!11642650!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1391 invoked from network); 10 May 2012 14:50:11 -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; 10 May 2012 14:50:11 -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 q4AEnwsp007214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 14:49: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 q4AEnvsZ013647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 14:49:58 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 q4AEnvUC026464; Thu, 10 May 2012 09:49:57 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 07:49:57 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 69DC64032D; Thu, 10 May 2012 10:43:53 -0400 (EDT) Date: Thu, 10 May 2012 10:43:53 -0400 From: Konrad Rzeszutek Wilk To: Lars Kurth Message-ID: <20120510144353.GJ26152@phenom.dumpdata.com> References: <4F912F15.2030202@xen.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4F912F15.2030202@xen.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: xen-api@lists.xen.org, xen-arm@lists.xen.org, xen-users@lists.xen.org, xen-devel@lists.xen.org Subject: Re: [XenARM] [Xen-API] Xen Documentation Day : April 23rd X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Fri, Apr 20, 2012 at 10:40:37AM +0100, Lars Kurth wrote: > Hi everybody, > > we have another Xen Documentation Day come up next Monday, April 23. When is the next one? I am itching to write some new docs! _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWz-0006ko-Qr; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4ti-00026u-J2 for xen-arm@lists.xen.org; Wed, 09 May 2012 11:17:35 +0000 Received: from [193.109.254.147:54319] by server-10.bemta-14.messagelabs.com id 0D/00-05847-D425AAF4; Wed, 09 May 2012 11:17:33 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-8.tower-27.messagelabs.com!1336562245!8398518!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11890 invoked from network); 9 May 2012 11:17:26 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:17:26 -0000 Received: by vbbfn1 with SMTP id fn1so234871vbb.32 for ; Wed, 09 May 2012 04:17:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ksy4Sm2M9P9+h47SjYcgosjhXKAm3/qobf9aXA0Irsw=; b=XpTahGfJnKNSEcxImxg/uYAs29O3IiVdvEfRl9OugdPkUAw8KPRXXqb6tS1cyCUcQV Yck155Vrs/JJvZldQNoFE33FcEKFogyKn21Y+Ie0XJFNxhUhs+ZO2hxsL4o5SQyMEoBC Z/7DgdxOoRrxSiWtMdofLmSBJBKtVZeizlfbhQGv7XXd6XIRFG4iMb1A3hevAsWaqugr G1HF4BRl6zgajDGHjggUN/02uWyRyQLNEjixZtzEStOMSRITuOJeZ8sw/cy6FDLnYexK tVRBcB5oKBVVhcGsFsqBWC3PD5R2qffEHhA+/cUIY09YHjvLRh+fgMa8onaNEmM0f42L FzcQ== Received: by 10.220.155.131 with SMTP id s3mr10605715vcw.15.1336562215355; Wed, 09 May 2012 04:16:55 -0700 (PDT) References:

<20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org>

<-3890923700307571348@unknownmsgid> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Wed, 9 May 2012 07:16:45 -0400 Message-ID: <-6403728154748147809@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQnNIZBB77ZMB6MzcTyC1pxCi55tDb27MYXd7Y3LvLKt+1eGWRTmtbznRbLevusv7i8EBKsh X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Christoffer Dall , Peter Maydell , "xen-arm@lists.xensource.com" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" , Xvisor Devel Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6673775517023200057==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============6673775517023200057== Content-Type: multipart/alternative; boundary=f46d04308a3a11046b04bf98a481 --f46d04308a3a11046b04bf98a481 Content-Type: text/plain; charset=ISO-8859-1 On May 9, 2012, at 2:11 AM, Anup Patel wrote: The intention behind the announcement was to inform people interested in virtualization about Xvisor. The announcement was an early info about achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planning to have scientific paper for Xvisor. consider the members of this list informed Also, I do agree that KVM ARM can be further optimized but as I mentioned in my previous replies "KVM ARM will end-up putting more and more stuff in-kernel". For now you can think of Xvisor ARM = KVM ARM doing everything in-kernel. Even Xvisor ARM is being optimized so, as time passes Xvisor ARM is also going to improve further. Its a common wisdom that "No hypervisor in the world can be better than Native performance". Xvisor ARM is already very very close to native performance and KVM ARM will come close to native performance only by increasing its monolithic nature (i.e. doing more things in-kernel). If monolithic hypervisors are so well performing then why not to have a monolithic hypervisor made for virtualization purpose only. The motivation behind writing Xvisor was the same. Apart from high performance Xvisor has many interesting features such as: *Ability to work without hardware virtualization support* - Xvisor ARM is able to boot multiple unmodified Linux guest even on hosts which do not have virtualization extensions implemented. In contrast, KVM ARM does not work without virtualization extension. The potential number of host hardware that Xvisor ARM can support is much more than KVM ARM can support. Xvisor ARM can in-fact run on old ARMv5 processors too. *Tree-based configuration* - To create a guest we have to just describe the guest in form of a device tree (possible even in runtime). In contrast, for KVM one needs to add the support in QEMU and recompile the binaries. *Pass-through hardware access* - For hardware not accessed or virtualized by Xvisor can be used in pass-through mode. Providing the guests a pass-through accessible device is just matter of adding a tree node and configure irq routing information in guest tree. Its not just PCI devices, we can provide any kind of device as pass-through accessible (Note: if device has in-built DMA then it should have IOMMU or SysMMU otherwise it would be security breach). We have already tried out Serial Port and NIC as pass-through devices. We can compare KVM advantages with Xvisor as follows: *Scheduler* - The linux kernel scheduler is very mature and proven OS scheduler but Hypervisor scheduler can be quite different. Scheduling processes and scheduling VMs can be very different problems. In case of VMs we can use info such as: amount of emulated IO done, amount of time spend in waiting for irq, etc for improving the quality of server consolidation. *Driver base* - Xvisor has and will have all driver framework APIs similar to Linux and driver porting will be just one-on-one replacement of APIs in most cases. *User space tools* - For starter Xvisor will use libvirt tools (or similar open source initiative) for remote management. *Co-existence host processes* - Xvisor is not an OS. Its made for virtualization only so no process. Ofcourse, Xvisor has internal threading framework but most of the time this background threads are sleeping doing nothing. All the management commands are provided by managment terminal daemon (which a background thread in Xvisor). This all sounds fantastic! But as I said, this list is for the development of KVM/ARM and not a place for arguing how fantastic Xvisor is as opposed to everything else. Please keep that in mind. I am looking forward to your paper. On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall wrote: > Anup, > > Thanks for providing info on your Xvisor project. However, this is a > mailing list for the development of KVM/ARM and not a scientific forum to > establish in theory which hypervisor "will always perform better than" > which other hypervisor. > > If you want to establish that your code base will always perform better > than all other hosted hypervisors, I strongly encourage you to submit a > paper about this in a peer reviewed conference. Personally I would find > that establishing such facts in a scientific way to be extremely > interesting. > > I understand that you wish to argue Xvisor's superiority in comparison to > KVM, but I disagree with your conclusions. The code path taken in KVM can > be optimized to be extremely short and all logic could be placed within the > KVM module. There are numerous other advantages to using KVM (existing > driver base, upstream kernel integration, compatibility with existing user > space tools, co-existence with native host processes, etc.) and with server > grade hardware I see the reliance on the Linux kernel for scheduling, > memory management etc. to be a great advantage - and not a drawback. On the > other hand, when Xvisor matures, feature requests will only increase its > code size and complexity as well. > > -Christoffer > > On May 6, 2012, at 7:53 AM, Anup Patel wrote: > > Hi PMM, > > Whether to consider model for measuring performance is one's own opinion. > There are number of Tier1 conferences which accept simulation numbers for > proving better approaches provided the simulation platform is well accepted > by everyone. > > Talking about code sequences both Xvisor ARM and KVM ARM have same set of > emulators and drivers. In fact, almost all emulation code has been adopted > from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike > KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to > guest mode and amount of code traversed in handling any fault is also very > less hence Xvisor-ARM will have much less code executed compared to KVM ARM. > > In Xvisor developement, we have observed that results of any CPU > performance test on QEMU or Fast Model naturally scales up on > real-hardware. Atleast we have never come across any scenario or test > performing better on QEMU or Fast Model compared real-world (this is true > for test running on Native Linux or Linux running as guest on Xvisor ARM). > > In our opinion we strongly believe monolithic approaches are always better > performing over micro-kernelized approaches (or approaches somewhere in > between micro-kernel and monolithic). Hence Xvisor ARM will always perform > better than KVM ARM in theory, simulation and real-world. > > Best Regards, > Anup Patel > > On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > >> On 6 May 2012 05:22, Anup Patel wrote: >> > Also can you give example of a code sequence which is faster on model >> and >> > slower in real world. As far as I know ARM fast models are internally >> TLM >> > based models and If a TLM based model is emulating a timer chip of X >> clock >> > then it is quite precise X clock. >> >> Support for TLM does not require that the underlying model is cycle >> accurate (you can have 'loosely timed' behaviour). >> >> You might want to read the Fast Models documentation, which tries >> to be clear about what the models do and don't provide. In particular: >> >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html >> "Fast models cannot be used to: >> * model cycle counting >> * model software performance >> " >> >> > Ofcourse CPU emulation and computation >> > power will be less compared to real world. To see this behaviour try to >> boot >> > linux on Fast model or QEMU and leave it for hours and come back see the >> > time elapsed, you will definitely see same amount of time elapsed as >> real >> > world. >> >> Nobody's arguing that the models are faster than hardware! >> Let's try a simple example with some numbers representing >> relative speeds: >> >> operation A: h/w: 1 ; model 5 >> operation B: h/w 3 ; model 30 >> >> Where we're comparing two equivalent code sequences "A A A A" vs "B". >> On hardware "B" will be faster. On the model the "A A A A" beats "B". >> (both sequences are slower on the model than on the hardware, obviously.) >> >> The point is that some operations will be vastly vastly slower >> on the model, and some operations merely moderately slower. Which >> of any two code sequences is fastest depends at least as much on >> whether it's using operations that are disproportionally worse >> on the model. A trivial example of this is VFP -- certainly QEMU >> has to do complex software emulation of the floating point ops to >> maintain bit-for-bit accuracy, which makes them very slow to the >> point where a hand-optimised-integer-assembly codec is likely to >> be faster on the model than a Neon/VFP-using codec, even though >> of course the Neon codec will be faster on hardware. >> >> [NB: this is itself a big simplification: model performance will >> depend on a lot of interacting things and is not purely a >> same-every-time slowdown per operation. Some operations effectively >> slow down what happens after them, for instance on QEMU if you do >> something that makes us flush our cache of translated code. And >> if for instance you have a periodic timer then the fact the model >> is generally slower means you execute proportionally more insns in >> the timer interrupt, so inefficiency or slowness in that code path >> has disproportionately more effect on overall speed than it does >> on hardware. There are other complications too...] >> >> > The results in the announcemnt are not baseless we have quite amount >> reasons >> > to believe Xvisor ARM will perform better than KVM ARM in real-world >> too. >> >> I'm not stating a position on whether KVM will be better or worse >> than Xvisor. I'm just pointing out that you can't base an argument >> on the faulty assumption that performance inside a model can tell >> you anything useful about performance on hardware. >> >> -- PMM >> > > _______________________________________________ > Android-virt mailing list > Android-virt@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > > --f46d04308a3a11046b04bf98a481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On May 9, = 2012, at 2:11 AM, Anup Patel <anu= p@brainfault.org> wrote:

The intention behind the announcement was to inform people interested in v= irtualization about Xvisor. The announcement was an early info about achiev= ements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planni= ng to have scientific paper for Xvisor.

consider the members of this list informed

Also, I do agree that KVM ARM can be fu= rther optimized but as I mentioned in my previous replies "KVM ARM wil= l end-up putting more and more stuff in-kernel". For now you can think= of Xvisor ARM =3D KVM ARM doing everything in-kernel. Even Xvisor ARM is b= eing optimized so, as time passes Xvisor ARM is also going to improve furth= er. Its a common wisdom that "No hypervisor in the world can be better= than Native performance". Xvisor ARM is already very very close to na= tive performance and KVM ARM will come close to native performance only by = increasing its monolithic nature (i.e. doing more things in-kernel). If mon= olithic hypervisors are so well performing then why not to have a monolithi= c hypervisor made for virtualization purpose only. The motivation behind wr= iting Xvisor was the same.

Apart from high performance Xvisor has many interesting features such a= s:
Ability to work without hardware virtualization support - Xvis= or ARM is able to boot multiple unmodified Linux guest even on hosts which = do not have virtualization extensions implemented. In contrast, KVM ARM doe= s not work without virtualization extension. The potential number of host h= ardware that Xvisor ARM can support is much more than KVM ARM can support. = Xvisor ARM can in-fact run on old ARMv5 processors too.
Tree-based configuration - To create a guest we have to just describ= e the guest in form of a device tree (possible even in runtime). In contras= t, for KVM one needs to add the support in QEMU and recompile the binaries.=
Pass-through hardware access - For hardware not accessed or virtuali= zed by Xvisor can be used in pass-through mode. Providing the guests a pass= -through accessible device is just matter of adding a tree node and configu= re irq routing information in guest tree. Its not just PCI devices, we can = provide any kind of device as pass-through accessible (Note: if device has = in-built DMA then it should have IOMMU or SysMMU otherwise it would be secu= rity breach). We have already tried out Serial Port and NIC as pass-through= devices.

We can compare KVM advantages with Xvisor as follows:
Scheduler - The linux kernel scheduler is very mature and proven OS scheduler but = Hypervisor scheduler can be quite different. Scheduling processes and sched= uling VMs can be very different problems. In case of VMs we can use info su= ch as: amount of emulated IO done, amount of time spend in waiting for irq,= etc for improving the quality of server consolidation.
Driver base - Xvisor has and will have all driver framework APIs sim= ilar to Linux and driver porting will be just one-on-one replacement of API= s in most cases.
User space tools - For starter Xvisor will use = libvirt tools (or similar open source initiative) for remote management. Co-existence host processes - Xvisor is not an OS. Its made for virt= ualization only so no process. Ofcourse, Xvisor has internal threading fram= ework but most of the time this background threads are sleeping doing nothi= ng. All the management commands are provided by managment terminal daemon (= which a background thread in Xvisor).

This all sounds fantastic!

But as I said, this list is for the development of KVM/ARM = and not a place for arguing how fantastic Xvisor is as opposed to everythin= g else. Please keep that in mind.=A0

I am looking forward to your paper.=A0

On Wed, May 9, 2012 = at 4:29 AM, Christoffer Dall <cdall@cs.columbia.edu> wro= te:

Anup,

Thanks for pro= viding info on your Xvisor project. However, this is a mailing list for the= development of KVM/ARM and not a scientific forum to establish in theory w= hich hypervisor "will always perform better than" which oth= er hypervisor.

If you want to establish that your c= ode base will always perform better than all other hosted hypervisors, I st= rongly encourage you to submit a paper about this in a peer reviewed confer= ence. Personally I would find that establishing such facts in a scientific = way to be extremely interesting.=A0

I understand that you w= ish to argue Xvisor's superiority in comparison to KVM, but I disagree = with your conclusions. The code path taken in KVM can be optimized to be ex= tremely short and all logic could be placed within the KVM module. There ar= e numerous other advantages to using KVM (existing driver base, upstream ke= rnel integration, compatibility with existing user space tools, co-existenc= e with native host processes, etc.) and with server grade hardware I see th= e reliance on the Linux kernel for scheduling, memory management etc. to be= a great advantage - and not a drawback. On the other hand, when Xvisor mat= ures, feature requests will only increase its code size and complexity as w= ell.

-Christoffer

On May 6, 2012, at 7:53 AM, Anup Patel <anup@brainfault.org> w= rote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup Patel <anup@brainfault.org> wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0 http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

_______= ________________________________________
Android-virt maili= ng list
Android-virt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/and= roid-virt

--f46d04308a3a11046b04bf98a481-- --===============6673775517023200057== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============6673775517023200057==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWy-0006jh-VY; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQuKT-0006Gd-JC for xen-arm@lists.xen.org; Sun, 06 May 2012 05:48:21 +0000 Received: from [85.158.138.51:4031] by server-5.bemta-3.messagelabs.com id FB/5B-17113-4A016AF4; Sun, 06 May 2012 05:48:20 +0000 X-Env-Sender: hschauhan@nulltrace.org X-Msg-Ref: server-6.tower-174.messagelabs.com!1336283296!19443023!1 X-Originating-IP: [209.85.160.169] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6854 invoked from network); 6 May 2012 05:48:19 -0000 Received: from mail-gh0-f169.google.com (HELO mail-gy0-f169.google.com) (209.85.160.169) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 05:48:19 -0000 Received: by ghrr18 with SMTP id r18so3736873ghr.28 for ; Sat, 05 May 2012 22:48:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=uVY1tP0ul+KugJvNBoQGdLkFeSVFbOWTregpXiz0RVI=; b=oSqvn8jzQXgPHSSJ+dR2HKmUjJekxhwUhqXjwEbUQGxIPlAUoEJboXVaImKlbEenq4 Cjwb1BWby0oIuNTokO5Sp7i96kxZddCMcxeYgfNNakyMNhIEiD8xEPefCXdBItsNp5NB Zqnewh5tJlVhDBKPfad/chNYkmSPodEXgr1oimljervOZPI/l4uBzJmWGc3u2HQkYCHq 8sOBUAiVDW5vnGwfswPHOrSCvXYh5oI44hTUk46DMtnVkoR4KksrreZwCfjB5wZDMxEK ZeS752qf+GGAD/9UDi8s6FawBPvPumGZOP2fEtHE8IaHu/uknY6Pgzjrgq/lU/KR7xI4 gQHw== Received: by 10.236.181.42 with SMTP id k30mr4571202yhm.42.1336283296333; Sat, 05 May 2012 22:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.123.6 with HTTP; Sat, 5 May 2012 22:47:35 -0700 (PDT) X-Originating-IP: [122.167.110.121] In-Reply-To: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> References: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> From: "Chauhan, Himanshu" Date: Sun, 6 May 2012 11:17:35 +0530 Message-ID: To: xvisor-devel@googlegroups.com X-Gm-Message-State: ALoCoQnxCG1B7FN8PSk/tkbfFQRjAe2Gelj8kQk/zwM7pjDluXu7uvq6ANwoPBB4ldfKMLnrZlko X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: "xen-arm@lists.xen.org" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" , Peter Maydell Subject: Re: [XenARM] [xvisor-devel] Re: [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8845020324005984930==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============8845020324005984930== Content-Type: multipart/alternative; boundary=20cf305b0f9a32802204bf57b3d3 --20cf305b0f9a32802204bf57b3d3 Content-Type: text/plain; charset=ISO-8859-1 > The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. > > On the Fast Model. > > To quote from ARM site: "the Fast Models can help developers debug, analyze, and __optimize__ their applications throughout the development cycle." If fast models are not as is (which I understand they don't represent the microarchitecture), why care about optimizations in fast model then? I believe if X-Visor wins on fast model on what ever reasons, it WILL win on hardware as well. We must accept this. = Himanshu = --20cf305b0f9a32802204bf57b3d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > The previous announcement only proves that Xvisor ARM is relatively be= tter than KVM ARM.

On the Fast Model.

To quote from ARM site:

"the Fast Models= can help developers debug, analyze, and __optimize__ their applications th= roughout the development cycle."

If fast models are not as is (= which I understand they don't represent the microarchitecture), why car= e about optimizations in fast model then?

I believe if X-Visor wins on fast model on what ever reasons, it WILL w= in on hardware as well. We must accept this.

=3D Himanshu =3D

--20cf305b0f9a32802204bf57b3d3-- --===============8845020324005984930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============8845020324005984930==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWy-0006jT-Pu; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQgh2-0005d7-7A for xen-arm@lists.xensource.com; Sat, 05 May 2012 15:14:44 +0000 Received: from [85.158.143.99:9520] by server-1.bemta-4.messagelabs.com id 2B/A9-20925-3E345AF4; Sat, 05 May 2012 15:14:43 +0000 X-Env-Sender: marc.zyngier@arm.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336230882!20246794!1 X-Originating-IP: [91.220.42.44] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDIxNzM4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31302 invoked from network); 5 May 2012 15:14:42 -0000 Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by server-10.tower-216.messagelabs.com with SMTP; 5 May 2012 15:14:42 -0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Sat, 05 May 2012 16:14:41 +0100 Received: from taxman.wild-wind.fr.eu.org ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 May 2012 16:16:12 +0100 Date: Sat, 5 May 2012 16:14:36 +0100 From: Marc Zyngier To: Anup Patel Message-ID: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> In-Reply-To: References: Organization: ARM Ltd X-Mailer: Claws Mail 3.8.0 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-OriginalArrivalTime: 05 May 2012 15:16:12.0592 (UTC) FILETIME=[01D61B00:01CD2AD2] X-MC-Unique: 112050516144100201 X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Sat, 5 May 2012 15:31:36 +0100 Anup Patel wrote: > Hi PMM, > > Also in my-view even if we have in-kernel emulation of irqchip and timer still Xvisor ARM will be performing better than KVM ARM because amount of code path traversed in KVM ARM will always be more. > > (Please note my-view about in-kernel emulation is totally based on code flow comparison of Xvisor ARM emulation and possible KVM ARM in-kernel emulation) > Sweet. Can I borrow your crystal ball? M. > On Sat, May 5, 2012 at 7:54 PM, Anup Patel > wrote: > Hi PMM, > > I agree we cannot predict real world performance based on performance on ARM fast models but if system A is performing better than system B no ARM fast model or QEMU then in real world system A will perform better than system B. Of-course in real world scale of difference in performance between system A and system B will differ. > > The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. > > Regards, > --Anup > > > On Sat, May 5, 2012 at 3:36 PM, Peter Maydell > wrote: > 2012/5/5 Anup Patel >: > > This announcement is to show an apple to apple performance comparison > > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. > > I would strongly caution against trying to do any performance/timing > type tests if you're still running on the ARM Fast Model -- they are > not representative of performance characteristics on hardware > and you really can't draw any conclusions about real world > performance by timing things on a model. It's quite easy to get > into a situation where all you're measuring is "does my code happen > to do a lot of some perfectly reasonable operation which happens > to be hard and slow to implement for the model?". > > (Also, KVM for ARM is still under development and we haven't > yet made several of the obvious performance improvements like > in-kernel irqchip and timer support, so it's not really a very > useful thing to compare against yet.) > > -- PMM > > -- I'm the slime oozin' out from your TV set... _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWy-0006j7-FT; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQbsk-0003rD-Od for xen-arm@lists.xen.org; Sat, 05 May 2012 10:06:30 +0000 Received: from [85.158.139.83:29987] by server-11.bemta-5.messagelabs.com id 4B/6A-12959-5ABF4AF4; Sat, 05 May 2012 10:06:29 +0000 X-Env-Sender: peter.maydell@linaro.org X-Msg-Ref: server-4.tower-182.messagelabs.com!1336212387!24171957!1 X-Originating-IP: [209.85.214.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9474 invoked from network); 5 May 2012 10:06:29 -0000 Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 10:06:29 -0000 Received: by obbwd20 with SMTP id wd20so6944063obb.32 for ; Sat, 05 May 2012 03:06:27 -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=sMZ4Wd0pTPl76B3K/zj9MZpmHlob7CHkply9MapD//A=; b=nayjRBWHoGi9yBwGrKVSoCWgOD0xPzgxQiaW2urFqxZLyXt9fj1hC5BJf/hnrkcsEJ f5w3YYYOqLXp0j7N26ff9RRwWsUrP3cMWDP5PfKVhCtsw5IKYwW5ANdHw/Yps9wK/kRo ZojZBO/B9DaSnT3BdJtGYV3nykVdnx9o40QV9gnU0S9t7gkKnhUQB1t/ng3gu3n3r+na DfdfVPzbCsvuCmRX3htmmUam1peb7l8lw0qvXuNaUSAbdCYQOVKBUGbFPaQZgxF/HkQb gp9oO4YDydCDy3FEaZz5HzpdhKdlR/AxO6ljgOrABx+NNQIft18ciY9sSXgsj4PWh4VG wwzg== MIME-Version: 1.0 Received: by 10.50.188.138 with SMTP id ga10mr4779729igc.51.1336212387319; Sat, 05 May 2012 03:06:27 -0700 (PDT) Received: by 10.50.100.198 with HTTP; Sat, 5 May 2012 03:06:27 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 May 2012 11:06:27 +0100 Message-ID: From: Peter Maydell To: Anup Patel X-Gm-Message-State: ALoCoQlIzBgZiIx7pvP+79NTVzlw0ATh8uCCsQuLRaaGflzVqefUOjlyOf56zuyhOzKKVoqiyxeb X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: xen-arm@lists.xensource.com, Xvisor Devel , android-virt@lists.cs.columbia.edu, xen-arm@lists.xen.org Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org 2012/5/5 Anup Patel : > This announcement is to show an apple to apple performance comparison > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. I would strongly caution against trying to do any performance/timing type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware and you really can't draw any conclusions about real world performance by timing things on a model. It's quite easy to get into a situation where all you're measuring is "does my code happen to do a lot of some perfectly reasonable operation which happens to be hard and slow to implement for the model?". (Also, KVM for ARM is still under development and we haven't yet made several of the obvious performance improvements like in-kernel irqchip and timer support, so it's not really a very useful thing to compare against yet.) -- PMM _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWz-0006ko-Qr; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4ti-00026u-J2 for xen-arm@lists.xen.org; Wed, 09 May 2012 11:17:35 +0000 Received: from [193.109.254.147:54319] by server-10.bemta-14.messagelabs.com id 0D/00-05847-D425AAF4; Wed, 09 May 2012 11:17:33 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-8.tower-27.messagelabs.com!1336562245!8398518!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11890 invoked from network); 9 May 2012 11:17:26 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:17:26 -0000 Received: by vbbfn1 with SMTP id fn1so234871vbb.32 for ; Wed, 09 May 2012 04:17:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ksy4Sm2M9P9+h47SjYcgosjhXKAm3/qobf9aXA0Irsw=; b=XpTahGfJnKNSEcxImxg/uYAs29O3IiVdvEfRl9OugdPkUAw8KPRXXqb6tS1cyCUcQV Yck155Vrs/JJvZldQNoFE33FcEKFogyKn21Y+Ie0XJFNxhUhs+ZO2hxsL4o5SQyMEoBC Z/7DgdxOoRrxSiWtMdofLmSBJBKtVZeizlfbhQGv7XXd6XIRFG4iMb1A3hevAsWaqugr G1HF4BRl6zgajDGHjggUN/02uWyRyQLNEjixZtzEStOMSRITuOJeZ8sw/cy6FDLnYexK tVRBcB5oKBVVhcGsFsqBWC3PD5R2qffEHhA+/cUIY09YHjvLRh+fgMa8onaNEmM0f42L FzcQ== Received: by 10.220.155.131 with SMTP id s3mr10605715vcw.15.1336562215355; Wed, 09 May 2012 04:16:55 -0700 (PDT) References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> <-3890923700307571348@unknownmsgid> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Wed, 9 May 2012 07:16:45 -0400 Message-ID: <-6403728154748147809@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQnNIZBB77ZMB6MzcTyC1pxCi55tDb27MYXd7Y3LvLKt+1eGWRTmtbznRbLevusv7i8EBKsh X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Christoffer Dall , Peter Maydell , "xen-arm@lists.xensource.com" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" , Xvisor Devel Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6673775517023200057==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============6673775517023200057== Content-Type: multipart/alternative; boundary=f46d04308a3a11046b04bf98a481 --f46d04308a3a11046b04bf98a481 Content-Type: text/plain; charset=ISO-8859-1 On May 9, 2012, at 2:11 AM, Anup Patel wrote: The intention behind the announcement was to inform people interested in virtualization about Xvisor. The announcement was an early info about achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planning to have scientific paper for Xvisor. consider the members of this list informed Also, I do agree that KVM ARM can be further optimized but as I mentioned in my previous replies "KVM ARM will end-up putting more and more stuff in-kernel". For now you can think of Xvisor ARM = KVM ARM doing everything in-kernel. Even Xvisor ARM is being optimized so, as time passes Xvisor ARM is also going to improve further. Its a common wisdom that "No hypervisor in the world can be better than Native performance". Xvisor ARM is already very very close to native performance and KVM ARM will come close to native performance only by increasing its monolithic nature (i.e. doing more things in-kernel). If monolithic hypervisors are so well performing then why not to have a monolithic hypervisor made for virtualization purpose only. The motivation behind writing Xvisor was the same. Apart from high performance Xvisor has many interesting features such as: *Ability to work without hardware virtualization support* - Xvisor ARM is able to boot multiple unmodified Linux guest even on hosts which do not have virtualization extensions implemented. In contrast, KVM ARM does not work without virtualization extension. The potential number of host hardware that Xvisor ARM can support is much more than KVM ARM can support. Xvisor ARM can in-fact run on old ARMv5 processors too. *Tree-based configuration* - To create a guest we have to just describe the guest in form of a device tree (possible even in runtime). In contrast, for KVM one needs to add the support in QEMU and recompile the binaries. *Pass-through hardware access* - For hardware not accessed or virtualized by Xvisor can be used in pass-through mode. Providing the guests a pass-through accessible device is just matter of adding a tree node and configure irq routing information in guest tree. Its not just PCI devices, we can provide any kind of device as pass-through accessible (Note: if device has in-built DMA then it should have IOMMU or SysMMU otherwise it would be security breach). We have already tried out Serial Port and NIC as pass-through devices. We can compare KVM advantages with Xvisor as follows: *Scheduler* - The linux kernel scheduler is very mature and proven OS scheduler but Hypervisor scheduler can be quite different. Scheduling processes and scheduling VMs can be very different problems. In case of VMs we can use info such as: amount of emulated IO done, amount of time spend in waiting for irq, etc for improving the quality of server consolidation. *Driver base* - Xvisor has and will have all driver framework APIs similar to Linux and driver porting will be just one-on-one replacement of APIs in most cases. *User space tools* - For starter Xvisor will use libvirt tools (or similar open source initiative) for remote management. *Co-existence host processes* - Xvisor is not an OS. Its made for virtualization only so no process. Ofcourse, Xvisor has internal threading framework but most of the time this background threads are sleeping doing nothing. All the management commands are provided by managment terminal daemon (which a background thread in Xvisor). This all sounds fantastic! But as I said, this list is for the development of KVM/ARM and not a place for arguing how fantastic Xvisor is as opposed to everything else. Please keep that in mind. I am looking forward to your paper. On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall wrote: > Anup, > > Thanks for providing info on your Xvisor project. However, this is a > mailing list for the development of KVM/ARM and not a scientific forum to > establish in theory which hypervisor "will always perform better than" > which other hypervisor. > > If you want to establish that your code base will always perform better > than all other hosted hypervisors, I strongly encourage you to submit a > paper about this in a peer reviewed conference. Personally I would find > that establishing such facts in a scientific way to be extremely > interesting. > > I understand that you wish to argue Xvisor's superiority in comparison to > KVM, but I disagree with your conclusions. The code path taken in KVM can > be optimized to be extremely short and all logic could be placed within the > KVM module. There are numerous other advantages to using KVM (existing > driver base, upstream kernel integration, compatibility with existing user > space tools, co-existence with native host processes, etc.) and with server > grade hardware I see the reliance on the Linux kernel for scheduling, > memory management etc. to be a great advantage - and not a drawback. On the > other hand, when Xvisor matures, feature requests will only increase its > code size and complexity as well. > > -Christoffer > > On May 6, 2012, at 7:53 AM, Anup Patel wrote: > > Hi PMM, > > Whether to consider model for measuring performance is one's own opinion. > There are number of Tier1 conferences which accept simulation numbers for > proving better approaches provided the simulation platform is well accepted > by everyone. > > Talking about code sequences both Xvisor ARM and KVM ARM have same set of > emulators and drivers. In fact, almost all emulation code has been adopted > from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike > KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to > guest mode and amount of code traversed in handling any fault is also very > less hence Xvisor-ARM will have much less code executed compared to KVM ARM. > > In Xvisor developement, we have observed that results of any CPU > performance test on QEMU or Fast Model naturally scales up on > real-hardware. Atleast we have never come across any scenario or test > performing better on QEMU or Fast Model compared real-world (this is true > for test running on Native Linux or Linux running as guest on Xvisor ARM). > > In our opinion we strongly believe monolithic approaches are always better > performing over micro-kernelized approaches (or approaches somewhere in > between micro-kernel and monolithic). Hence Xvisor ARM will always perform > better than KVM ARM in theory, simulation and real-world. > > Best Regards, > Anup Patel > > On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > >> On 6 May 2012 05:22, Anup Patel wrote: >> > Also can you give example of a code sequence which is faster on model >> and >> > slower in real world. As far as I know ARM fast models are internally >> TLM >> > based models and If a TLM based model is emulating a timer chip of X >> clock >> > then it is quite precise X clock. >> >> Support for TLM does not require that the underlying model is cycle >> accurate (you can have 'loosely timed' behaviour). >> >> You might want to read the Fast Models documentation, which tries >> to be clear about what the models do and don't provide. In particular: >> >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html >> "Fast models cannot be used to: >> * model cycle counting >> * model software performance >> " >> >> > Ofcourse CPU emulation and computation >> > power will be less compared to real world. To see this behaviour try to >> boot >> > linux on Fast model or QEMU and leave it for hours and come back see the >> > time elapsed, you will definitely see same amount of time elapsed as >> real >> > world. >> >> Nobody's arguing that the models are faster than hardware! >> Let's try a simple example with some numbers representing >> relative speeds: >> >> operation A: h/w: 1 ; model 5 >> operation B: h/w 3 ; model 30 >> >> Where we're comparing two equivalent code sequences "A A A A" vs "B". >> On hardware "B" will be faster. On the model the "A A A A" beats "B". >> (both sequences are slower on the model than on the hardware, obviously.) >> >> The point is that some operations will be vastly vastly slower >> on the model, and some operations merely moderately slower. Which >> of any two code sequences is fastest depends at least as much on >> whether it's using operations that are disproportionally worse >> on the model. A trivial example of this is VFP -- certainly QEMU >> has to do complex software emulation of the floating point ops to >> maintain bit-for-bit accuracy, which makes them very slow to the >> point where a hand-optimised-integer-assembly codec is likely to >> be faster on the model than a Neon/VFP-using codec, even though >> of course the Neon codec will be faster on hardware. >> >> [NB: this is itself a big simplification: model performance will >> depend on a lot of interacting things and is not purely a >> same-every-time slowdown per operation. Some operations effectively >> slow down what happens after them, for instance on QEMU if you do >> something that makes us flush our cache of translated code. And >> if for instance you have a periodic timer then the fact the model >> is generally slower means you execute proportionally more insns in >> the timer interrupt, so inefficiency or slowness in that code path >> has disproportionately more effect on overall speed than it does >> on hardware. There are other complications too...] >> >> > The results in the announcemnt are not baseless we have quite amount >> reasons >> > to believe Xvisor ARM will perform better than KVM ARM in real-world >> too. >> >> I'm not stating a position on whether KVM will be better or worse >> than Xvisor. I'm just pointing out that you can't base an argument >> on the faulty assumption that performance inside a model can tell >> you anything useful about performance on hardware. >> >> -- PMM >> > > _______________________________________________ > Android-virt mailing list > Android-virt@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > > --f46d04308a3a11046b04bf98a481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On May 9, = 2012, at 2:11 AM, Anup Patel <anu= p@brainfault.org> wrote:

The intention behind the announcement was to inform people interested in v= irtualization about Xvisor. The announcement was an early info about achiev= ements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planni= ng to have scientific paper for Xvisor.

consider the members of this list informed
Also, I do agree that KVM ARM can be fu= rther optimized but as I mentioned in my previous replies "KVM ARM wil= l end-up putting more and more stuff in-kernel". For now you can think= of Xvisor ARM =3D KVM ARM doing everything in-kernel. Even Xvisor ARM is b= eing optimized so, as time passes Xvisor ARM is also going to improve furth= er. Its a common wisdom that "No hypervisor in the world can be better= than Native performance". Xvisor ARM is already very very close to na= tive performance and KVM ARM will come close to native performance only by = increasing its monolithic nature (i.e. doing more things in-kernel). If mon= olithic hypervisors are so well performing then why not to have a monolithi= c hypervisor made for virtualization purpose only. The motivation behind wr= iting Xvisor was the same.

Apart from high performance Xvisor has many interesting features such a= s:
Ability to work without hardware virtualization support - Xvis= or ARM is able to boot multiple unmodified Linux guest even on hosts which = do not have virtualization extensions implemented. In contrast, KVM ARM doe= s not work without virtualization extension. The potential number of host h= ardware that Xvisor ARM can support is much more than KVM ARM can support. = Xvisor ARM can in-fact run on old ARMv5 processors too.
Tree-based configuration - To create a guest we have to just describ= e the guest in form of a device tree (possible even in runtime). In contras= t, for KVM one needs to add the support in QEMU and recompile the binaries.=
Pass-through hardware access - For hardware not accessed or virtuali= zed by Xvisor can be used in pass-through mode. Providing the guests a pass= -through accessible device is just matter of adding a tree node and configu= re irq routing information in guest tree. Its not just PCI devices, we can = provide any kind of device as pass-through accessible (Note: if device has = in-built DMA then it should have IOMMU or SysMMU otherwise it would be secu= rity breach). We have already tried out Serial Port and NIC as pass-through= devices.

We can compare KVM advantages with Xvisor as follows:
Scheduler - The linux kernel scheduler is very mature and proven OS scheduler but = Hypervisor scheduler can be quite different. Scheduling processes and sched= uling VMs can be very different problems. In case of VMs we can use info su= ch as: amount of emulated IO done, amount of time spend in waiting for irq,= etc for improving the quality of server consolidation.
Driver base - Xvisor has and will have all driver framework APIs sim= ilar to Linux and driver porting will be just one-on-one replacement of API= s in most cases.
User space tools - For starter Xvisor will use = libvirt tools (or similar open source initiative) for remote management. Co-existence host processes - Xvisor is not an OS. Its made for virt= ualization only so no process. Ofcourse, Xvisor has internal threading fram= ework but most of the time this background threads are sleeping doing nothi= ng. All the management commands are provided by managment terminal daemon (= which a background thread in Xvisor).

This all sounds fantastic!

But as I said, this list is for the development of KVM/ARM = and not a place for arguing how fantastic Xvisor is as opposed to everythin= g else. Please keep that in mind.=A0

I am looking forward to your paper.=A0

On Wed, May 9, 2012 = at 4:29 AM, Christoffer Dall <cdall@cs.columbia.edu> wro= te:

Anup,

Thanks for pro= viding info on your Xvisor project. However, this is a mailing list for the= development of KVM/ARM and not a scientific forum to establish in theory w= hich hypervisor "will always perform better than" which oth= er hypervisor.

If you want to establish that your c= ode base will always perform better than all other hosted hypervisors, I st= rongly encourage you to submit a paper about this in a peer reviewed confer= ence. Personally I would find that establishing such facts in a scientific = way to be extremely interesting.=A0

I understand that you w= ish to argue Xvisor's superiority in comparison to KVM, but I disagree = with your conclusions. The code path taken in KVM can be optimized to be ex= tremely short and all logic could be placed within the KVM module. There ar= e numerous other advantages to using KVM (existing driver base, upstream ke= rnel integration, compatibility with existing user space tools, co-existenc= e with native host processes, etc.) and with server grade hardware I see th= e reliance on the Linux kernel for scheduling, memory management etc. to be= a great advantage - and not a drawback. On the other hand, when Xvisor mat= ures, feature requests will only increase its code size and complexity as w= ell.

-Christoffer

On May 6, 2012, at 7:53 AM, Anup Patel <anup@brainfault.org> w= rote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup Patel <anup@brainfault.org> wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0 http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

_______= ________________________________________
Android-virt maili= ng list
Android-virt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/and= roid-virt

--f46d04308a3a11046b04bf98a481-- --===============6673775517023200057== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============6673775517023200057==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWz-0006jn-2A; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxBf-0007qZ-Jg for xen-arm@lists.xensource.com; Sun, 06 May 2012 08:51:27 +0000 Received: from [85.158.139.83:43025] by server-12.bemta-5.messagelabs.com id 0D/FF-01344-E8B36AF4; Sun, 06 May 2012 08:51:26 +0000 X-Env-Sender: peter.maydell@linaro.org X-Msg-Ref: server-8.tower-182.messagelabs.com!1336294284!15702328!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17814 invoked from network); 6 May 2012 08:51:25 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 08:51:25 -0000 Received: by obfk16 with SMTP id k16so9130305obf.30 for ; Sun, 06 May 2012 01:51:24 -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=09ky27x81dl1OWxb/+i6b+OxXjqYpq0V7XsFRk7c/V0=; b=JBhNI1Qq5R6eN4IdCyr2sTNnIp3pNPgDvQ8VvANFtD3YCtLIil4Is40Ry5FdDzp+Ky vxfgxzmdHmPGunqVdRXLBSQ/dphOTIcCWL8JuMqU2EowzBfeVXgIT920JCjV+ZpjQLcs J02oWzWT9RIgRB0wAcxsFJHKmmbURxmJZSpUtFghTs1WZBIN29xXESqlyS8mu8hlt86S Q7O7klNfHvJdOJvZTWuOIxOjBrfsJDY9po5h1xT2ImvFAFsWzYNdpIAIE8tUs4I41DdR a81FmQUUJkMBh5vgv9lXCvIMWtx+7YLgwrpHUfIzEbhV7hGZhPAiAKWaU26QssY+GJK/ H+7w== MIME-Version: 1.0 Received: by 10.50.149.132 with SMTP id ua4mr6267094igb.41.1336294284255; Sun, 06 May 2012 01:51:24 -0700 (PDT) Received: by 10.50.100.198 with HTTP; Sun, 6 May 2012 01:51:24 -0700 (PDT) In-Reply-To: References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> Date: Sun, 6 May 2012 09:51:24 +0100 Message-ID: From: Peter Maydell To: Anup Patel X-Gm-Message-State: ALoCoQlkF2Ms7NJfrKs80fLOO0GzOVVZX8lQ2qm8Rl9Ii78mmZRV+QqRxvXGLyHQsmzmEygJsfb6 X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Marc Zyngier , "xen-arm@lists.xensource.com" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On 6 May 2012 05:22, Anup Patel wrote: > Also can you give example of a code sequence which is faster on model and > slower in real world. As far as I know ARM fast models are internally TLM > based models and If a TLM based model is emulating a timer chip of X clock > then it is quite precise X clock. Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour). You might want to read the Fast Models documentation, which tries to be clear about what the models do and don't provide. In particular: http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html "Fast models cannot be used to: * model cycle counting * model software performance " > Ofcourse CPU emulation and computation > power will be less compared to real world. To see this behaviour try to boot > linux on Fast model or QEMU and leave it for hours and come back see the > time elapsed, you will definitely see same amount of time elapsed as real > world. Nobody's arguing that the models are faster than hardware! Let's try a simple example with some numbers representing relative speeds: operation A: h/w: 1 ; model 5 operation B: h/w 3 ; model 30 Where we're comparing two equivalent code sequences "A A A A" vs "B". On hardware "B" will be faster. On the model the "A A A A" beats "B". (both sequences are slower on the model than on the hardware, obviously.) The point is that some operations will be vastly vastly slower on the model, and some operations merely moderately slower. Which of any two code sequences is fastest depends at least as much on whether it's using operations that are disproportionally worse on the model. A trivial example of this is VFP -- certainly QEMU has to do complex software emulation of the floating point ops to maintain bit-for-bit accuracy, which makes them very slow to the point where a hand-optimised-integer-assembly codec is likely to be faster on the model than a Neon/VFP-using codec, even though of course the Neon codec will be faster on hardware. [NB: this is itself a big simplification: model performance will depend on a lot of interacting things and is not purely a same-every-time slowdown per operation. Some operations effectively slow down what happens after them, for instance on QEMU if you do something that makes us flush our cache of translated code. And if for instance you have a periodic timer then the fact the model is generally slower means you execute proportionally more insns in the timer interrupt, so inefficiency or slowness in that code path has disproportionately more effect on overall speed than it does on hardware. There are other complications too...] > The results in the announcemnt are not baseless we have quite amount reasons > to believe Xvisor ARM will perform better than KVM ARM in real-world too. I'm not stating a position on whether KVM will be better or worse than Xvisor. I'm just pointing out that you can't base an argument on the faulty assumption that performance inside a model can tell you anything useful about performance on hardware. -- PMM _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWz-0006jx-8P; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRtNN-0003WK-DJ for xen-arm@lists.xen.org; Tue, 08 May 2012 22:59:25 +0000 Received: from [85.158.143.99:41101] by server-3.bemta-4.messagelabs.com id FA/66-05853-C45A9AF4; Tue, 08 May 2012 22:59:24 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-10.tower-216.messagelabs.com!1336517961!20689547!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13510 invoked from network); 8 May 2012 22:59:22 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 22:59:22 -0000 Received: by vbbfn1 with SMTP id fn1so1310054vbb.32 for ; Tue, 08 May 2012 15:59:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=2hrnN3xlahyNjwZHfBKaxq1ho6nKkmrWgX2el6KsidA=; b=NYQJQU4WJe4PT7S4nGNSueD1FJoxD8ESzp3uD5hvxIz23hcTU/tJr2MaGs9YoSK20A S8nhis6BautaE7nywd8t23uFVuBwRjuubeshammcMPDAO4TsGugIItRHZrXpYZWg3luj tUnIiud2taRY5ljLJEB2mnAbHxRYA2nY19EQusjmSDVRDXEW+o72SUXz/rpa742aqB92 5X5FDKn8s8b4ifF4GeSqEOkIN5hJXls08+BEeXlVa6hErw59z5fczEtjqGy1kQ/r6l5u ecszWX4FGGhp79GHVkZCUn02WW43AqEFhL3r/2CThmtlk4QYF8MhJOh9RNmgAHOW8QQL E8vw== Received: by 10.220.155.131 with SMTP id s3mr9405034vcw.15.1336517961316; Tue, 08 May 2012 15:59:21 -0700 (PDT) References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Tue, 8 May 2012 18:59:15 -0400 Message-ID: <-3890923700307571348@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQmgCrAn0N0J0GShwjpEvnkBufgK5kG74aJlwSLRvUtjxt3Wk/RTyM/XdZjo9kye/4aOidjv X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3587933770984734470==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============3587933770984734470== Content-Type: multipart/alternative; boundary=f46d04308a3a51fb7c04bf8e564f --f46d04308a3a51fb7c04bf8e564f Content-Type: text/plain; charset=ISO-8859-1 Anup, Thanks for providing info on your Xvisor project. However, this is a mailing list for the development of KVM/ARM and not a scientific forum to establish in theory which hypervisor "will always perform better than" which other hypervisor. If you want to establish that your code base will always perform better than all other hosted hypervisors, I strongly encourage you to submit a paper about this in a peer reviewed conference. Personally I would find that establishing such facts in a scientific way to be extremely interesting. I understand that you wish to argue Xvisor's superiority in comparison to KVM, but I disagree with your conclusions. The code path taken in KVM can be optimized to be extremely short and all logic could be placed within the KVM module. There are numerous other advantages to using KVM (existing driver base, upstream kernel integration, compatibility with existing user space tools, co-existence with native host processes, etc.) and with server grade hardware I see the reliance on the Linux kernel for scheduling, memory management etc. to be a great advantage - and not a drawback. On the other hand, when Xvisor matures, feature requests will only increase its code size and complexity as well. -Christoffer On May 6, 2012, at 7:53 AM, Anup Patel wrote: Hi PMM, Whether to consider model for measuring performance is one's own opinion. There are number of Tier1 conferences which accept simulation numbers for proving better approaches provided the simulation platform is well accepted by everyone. Talking about code sequences both Xvisor ARM and KVM ARM have same set of emulators and drivers. In fact, almost all emulation code has been adopted from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to guest mode and amount of code traversed in handling any fault is also very less hence Xvisor-ARM will have much less code executed compared to KVM ARM. In Xvisor developement, we have observed that results of any CPU performance test on QEMU or Fast Model naturally scales up on real-hardware. Atleast we have never come across any scenario or test performing better on QEMU or Fast Model compared real-world (this is true for test running on Native Linux or Linux running as guest on Xvisor ARM). In our opinion we strongly believe monolithic approaches are always better performing over micro-kernelized approaches (or approaches somewhere in between micro-kernel and monolithic). Hence Xvisor ARM will always perform better than KVM ARM in theory, simulation and real-world. Best Regards, Anup Patel On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > On 6 May 2012 05:22, Anup Patel wrote: > > Also can you give example of a code sequence which is faster on model and > > slower in real world. As far as I know ARM fast models are internally TLM > > based models and If a TLM based model is emulating a timer chip of X > clock > > then it is quite precise X clock. > > Support for TLM does not require that the underlying model is cycle > accurate (you can have 'loosely timed' behaviour). > > You might want to read the Fast Models documentation, which tries > to be clear about what the models do and don't provide. In particular: > http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html > "Fast models cannot be used to: > * model cycle counting > * model software performance > " > > > Ofcourse CPU emulation and computation > > power will be less compared to real world. To see this behaviour try to > boot > > linux on Fast model or QEMU and leave it for hours and come back see the > > time elapsed, you will definitely see same amount of time elapsed as real > > world. > > Nobody's arguing that the models are faster than hardware! > Let's try a simple example with some numbers representing > relative speeds: > > operation A: h/w: 1 ; model 5 > operation B: h/w 3 ; model 30 > > Where we're comparing two equivalent code sequences "A A A A" vs "B". > On hardware "B" will be faster. On the model the "A A A A" beats "B". > (both sequences are slower on the model than on the hardware, obviously.) > > The point is that some operations will be vastly vastly slower > on the model, and some operations merely moderately slower. Which > of any two code sequences is fastest depends at least as much on > whether it's using operations that are disproportionally worse > on the model. A trivial example of this is VFP -- certainly QEMU > has to do complex software emulation of the floating point ops to > maintain bit-for-bit accuracy, which makes them very slow to the > point where a hand-optimised-integer-assembly codec is likely to > be faster on the model than a Neon/VFP-using codec, even though > of course the Neon codec will be faster on hardware. > > [NB: this is itself a big simplification: model performance will > depend on a lot of interacting things and is not purely a > same-every-time slowdown per operation. Some operations effectively > slow down what happens after them, for instance on QEMU if you do > something that makes us flush our cache of translated code. And > if for instance you have a periodic timer then the fact the model > is generally slower means you execute proportionally more insns in > the timer interrupt, so inefficiency or slowness in that code path > has disproportionately more effect on overall speed than it does > on hardware. There are other complications too...] > > > The results in the announcemnt are not baseless we have quite amount > reasons > > to believe Xvisor ARM will perform better than KVM ARM in real-world too. > > I'm not stating a position on whether KVM will be better or worse > than Xvisor. I'm just pointing out that you can't base an argument > on the faulty assumption that performance inside a model can tell > you anything useful about performance on hardware. > > -- PMM > _______________________________________________ Android-virt mailing list Android-virt@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/android-virt --f46d04308a3a51fb7c04bf8e564f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Anup,

Thanks for providing info on your Xvisor project. However, this is a = mailing list for the development of KVM/ARM and not a scientific forum to e= stablish in theory which hypervisor "will always perform better than" which other hypervisor.<= /div>

If you want to establish that your code base = will always perform better than all other hosted hypervisors, I strongly en= courage you to submit a paper about this in a peer reviewed conference. Per= sonally I would find that establishing such facts in a scientific way to be= extremely interesting.=A0

<= div>I understand that you wish to ar= gue Xvisor's superiority in comparison to KVM, but I disagree with your= conclusions. The code path taken in KVM can be optimized to be extremely s= hort and all logic could be placed within the KVM module. There are numerou= s other advantages to using KVM (existing driver base, upstream kernel inte= gration, compatibility with existing user space tools, co-existence with na= tive host processes, etc.) and with server grade hardware I see the relianc= e on the Linux kernel for scheduling, memory management etc. to be a great = advantage - and not a drawback. On the other hand, when Xvisor matures, fea= ture requests will only increase its code size and complexity as well.

-Christoffer

On May 6, 2= 012, at 7:53 AM, Anup Patel <anup= @brainfault.org> wrote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup = Patel <anup@brainfault.org>= ; wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

___________________= ____________________________
Android-virt mailing list
Android-v= irt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/android-virt
--f46d04308a3a51fb7c04bf8e564f-- --===============3587933770984734470== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============3587933770984734470==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWz-0006jx-8P; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRtNN-0003WK-DJ for xen-arm@lists.xen.org; Tue, 08 May 2012 22:59:25 +0000 Received: from [85.158.143.99:41101] by server-3.bemta-4.messagelabs.com id FA/66-05853-C45A9AF4; Tue, 08 May 2012 22:59:24 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-10.tower-216.messagelabs.com!1336517961!20689547!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13510 invoked from network); 8 May 2012 22:59:22 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 22:59:22 -0000 Received: by vbbfn1 with SMTP id fn1so1310054vbb.32 for ; Tue, 08 May 2012 15:59:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=2hrnN3xlahyNjwZHfBKaxq1ho6nKkmrWgX2el6KsidA=; b=NYQJQU4WJe4PT7S4nGNSueD1FJoxD8ESzp3uD5hvxIz23hcTU/tJr2MaGs9YoSK20A S8nhis6BautaE7nywd8t23uFVuBwRjuubeshammcMPDAO4TsGugIItRHZrXpYZWg3luj tUnIiud2taRY5ljLJEB2mnAbHxRYA2nY19EQusjmSDVRDXEW+o72SUXz/rpa742aqB92 5X5FDKn8s8b4ifF4GeSqEOkIN5hJXls08+BEeXlVa6hErw59z5fczEtjqGy1kQ/r6l5u ecszWX4FGGhp79GHVkZCUn02WW43AqEFhL3r/2CThmtlk4QYF8MhJOh9RNmgAHOW8QQL E8vw== Received: by 10.220.155.131 with SMTP id s3mr9405034vcw.15.1336517961316; Tue, 08 May 2012 15:59:21 -0700 (PDT) References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Tue, 8 May 2012 18:59:15 -0400 Message-ID: <-3890923700307571348@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQmgCrAn0N0J0GShwjpEvnkBufgK5kG74aJlwSLRvUtjxt3Wk/RTyM/XdZjo9kye/4aOidjv X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3587933770984734470==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============3587933770984734470== Content-Type: multipart/alternative; boundary=f46d04308a3a51fb7c04bf8e564f --f46d04308a3a51fb7c04bf8e564f Content-Type: text/plain; charset=ISO-8859-1 Anup, Thanks for providing info on your Xvisor project. However, this is a mailing list for the development of KVM/ARM and not a scientific forum to establish in theory which hypervisor "will always perform better than" which other hypervisor. If you want to establish that your code base will always perform better than all other hosted hypervisors, I strongly encourage you to submit a paper about this in a peer reviewed conference. Personally I would find that establishing such facts in a scientific way to be extremely interesting. I understand that you wish to argue Xvisor's superiority in comparison to KVM, but I disagree with your conclusions. The code path taken in KVM can be optimized to be extremely short and all logic could be placed within the KVM module. There are numerous other advantages to using KVM (existing driver base, upstream kernel integration, compatibility with existing user space tools, co-existence with native host processes, etc.) and with server grade hardware I see the reliance on the Linux kernel for scheduling, memory management etc. to be a great advantage - and not a drawback. On the other hand, when Xvisor matures, feature requests will only increase its code size and complexity as well. -Christoffer On May 6, 2012, at 7:53 AM, Anup Patel wrote: Hi PMM, Whether to consider model for measuring performance is one's own opinion. There are number of Tier1 conferences which accept simulation numbers for proving better approaches provided the simulation platform is well accepted by everyone. Talking about code sequences both Xvisor ARM and KVM ARM have same set of emulators and drivers. In fact, almost all emulation code has been adopted from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to guest mode and amount of code traversed in handling any fault is also very less hence Xvisor-ARM will have much less code executed compared to KVM ARM. In Xvisor developement, we have observed that results of any CPU performance test on QEMU or Fast Model naturally scales up on real-hardware. Atleast we have never come across any scenario or test performing better on QEMU or Fast Model compared real-world (this is true for test running on Native Linux or Linux running as guest on Xvisor ARM). In our opinion we strongly believe monolithic approaches are always better performing over micro-kernelized approaches (or approaches somewhere in between micro-kernel and monolithic). Hence Xvisor ARM will always perform better than KVM ARM in theory, simulation and real-world. Best Regards, Anup Patel On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > On 6 May 2012 05:22, Anup Patel wrote: > > Also can you give example of a code sequence which is faster on model and > > slower in real world. As far as I know ARM fast models are internally TLM > > based models and If a TLM based model is emulating a timer chip of X > clock > > then it is quite precise X clock. > > Support for TLM does not require that the underlying model is cycle > accurate (you can have 'loosely timed' behaviour). > > You might want to read the Fast Models documentation, which tries > to be clear about what the models do and don't provide. In particular: > http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html > "Fast models cannot be used to: > * model cycle counting > * model software performance > " > > > Ofcourse CPU emulation and computation > > power will be less compared to real world. To see this behaviour try to > boot > > linux on Fast model or QEMU and leave it for hours and come back see the > > time elapsed, you will definitely see same amount of time elapsed as real > > world. > > Nobody's arguing that the models are faster than hardware! > Let's try a simple example with some numbers representing > relative speeds: > > operation A: h/w: 1 ; model 5 > operation B: h/w 3 ; model 30 > > Where we're comparing two equivalent code sequences "A A A A" vs "B". > On hardware "B" will be faster. On the model the "A A A A" beats "B". > (both sequences are slower on the model than on the hardware, obviously.) > > The point is that some operations will be vastly vastly slower > on the model, and some operations merely moderately slower. Which > of any two code sequences is fastest depends at least as much on > whether it's using operations that are disproportionally worse > on the model. A trivial example of this is VFP -- certainly QEMU > has to do complex software emulation of the floating point ops to > maintain bit-for-bit accuracy, which makes them very slow to the > point where a hand-optimised-integer-assembly codec is likely to > be faster on the model than a Neon/VFP-using codec, even though > of course the Neon codec will be faster on hardware. > > [NB: this is itself a big simplification: model performance will > depend on a lot of interacting things and is not purely a > same-every-time slowdown per operation. Some operations effectively > slow down what happens after them, for instance on QEMU if you do > something that makes us flush our cache of translated code. And > if for instance you have a periodic timer then the fact the model > is generally slower means you execute proportionally more insns in > the timer interrupt, so inefficiency or slowness in that code path > has disproportionately more effect on overall speed than it does > on hardware. There are other complications too...] > > > The results in the announcemnt are not baseless we have quite amount > reasons > > to believe Xvisor ARM will perform better than KVM ARM in real-world too. > > I'm not stating a position on whether KVM will be better or worse > than Xvisor. I'm just pointing out that you can't base an argument > on the faulty assumption that performance inside a model can tell > you anything useful about performance on hardware. > > -- PMM > _______________________________________________ Android-virt mailing list Android-virt@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/android-virt --f46d04308a3a51fb7c04bf8e564f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Anup,

Thanks for providing info on your Xvisor project. However, this is a = mailing list for the development of KVM/ARM and not a scientific forum to e= stablish in theory which hypervisor "will always perform better than" which other hypervisor.<= /div>

If you want to establish that your code base = will always perform better than all other hosted hypervisors, I strongly en= courage you to submit a paper about this in a peer reviewed conference. Per= sonally I would find that establishing such facts in a scientific way to be= extremely interesting.=A0

<= div>I understand that you wish to ar= gue Xvisor's superiority in comparison to KVM, but I disagree with your= conclusions. The code path taken in KVM can be optimized to be extremely s= hort and all logic could be placed within the KVM module. There are numerou= s other advantages to using KVM (existing driver base, upstream kernel inte= gration, compatibility with existing user space tools, co-existence with na= tive host processes, etc.) and with server grade hardware I see the relianc= e on the Linux kernel for scheduling, memory management etc. to be a great = advantage - and not a drawback. On the other hand, when Xvisor matures, fea= ture requests will only increase its code size and complexity as well.

-Christoffer

On May 6, 2= 012, at 7:53 AM, Anup Patel <anup= @brainfault.org> wrote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup = Patel <anup@brainfault.org>= ; wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

___________________= ____________________________
Android-virt mailing list
Android-v= irt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/android-virt
--f46d04308a3a51fb7c04bf8e564f-- --===============3587933770984734470== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============3587933770984734470==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWy-0006j7-FT; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQbsk-0003rD-Od for xen-arm@lists.xen.org; Sat, 05 May 2012 10:06:30 +0000 Received: from [85.158.139.83:29987] by server-11.bemta-5.messagelabs.com id 4B/6A-12959-5ABF4AF4; Sat, 05 May 2012 10:06:29 +0000 X-Env-Sender: peter.maydell@linaro.org X-Msg-Ref: server-4.tower-182.messagelabs.com!1336212387!24171957!1 X-Originating-IP: [209.85.214.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9474 invoked from network); 5 May 2012 10:06:29 -0000 Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 10:06:29 -0000 Received: by obbwd20 with SMTP id wd20so6944063obb.32 for ; Sat, 05 May 2012 03:06:27 -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=sMZ4Wd0pTPl76B3K/zj9MZpmHlob7CHkply9MapD//A=; b=nayjRBWHoGi9yBwGrKVSoCWgOD0xPzgxQiaW2urFqxZLyXt9fj1hC5BJf/hnrkcsEJ f5w3YYYOqLXp0j7N26ff9RRwWsUrP3cMWDP5PfKVhCtsw5IKYwW5ANdHw/Yps9wK/kRo ZojZBO/B9DaSnT3BdJtGYV3nykVdnx9o40QV9gnU0S9t7gkKnhUQB1t/ng3gu3n3r+na DfdfVPzbCsvuCmRX3htmmUam1peb7l8lw0qvXuNaUSAbdCYQOVKBUGbFPaQZgxF/HkQb gp9oO4YDydCDy3FEaZz5HzpdhKdlR/AxO6ljgOrABx+NNQIft18ciY9sSXgsj4PWh4VG wwzg== MIME-Version: 1.0 Received: by 10.50.188.138 with SMTP id ga10mr4779729igc.51.1336212387319; Sat, 05 May 2012 03:06:27 -0700 (PDT) Received: by 10.50.100.198 with HTTP; Sat, 5 May 2012 03:06:27 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 May 2012 11:06:27 +0100 Message-ID: From: Peter Maydell To: Anup Patel X-Gm-Message-State: ALoCoQlIzBgZiIx7pvP+79NTVzlw0ATh8uCCsQuLRaaGflzVqefUOjlyOf56zuyhOzKKVoqiyxeb X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: xen-arm@lists.xensource.com, Xvisor Devel , android-virt@lists.cs.columbia.edu, xen-arm@lists.xen.org Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org 2012/5/5 Anup Patel : > This announcement is to show an apple to apple performance comparison > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. I would strongly caution against trying to do any performance/timing type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware and you really can't draw any conclusions about real world performance by timing things on a model. It's quite easy to get into a situation where all you're measuring is "does my code happen to do a lot of some perfectly reasonable operation which happens to be hard and slow to implement for the model?". (Also, KVM for ARM is still under development and we haven't yet made several of the obvious performance improvements like in-kernel irqchip and timer support, so it's not really a very useful thing to compare against yet.) -- PMM _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWz-0006jn-2A; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxBf-0007qZ-Jg for xen-arm@lists.xensource.com; Sun, 06 May 2012 08:51:27 +0000 Received: from [85.158.139.83:43025] by server-12.bemta-5.messagelabs.com id 0D/FF-01344-E8B36AF4; Sun, 06 May 2012 08:51:26 +0000 X-Env-Sender: peter.maydell@linaro.org X-Msg-Ref: server-8.tower-182.messagelabs.com!1336294284!15702328!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17814 invoked from network); 6 May 2012 08:51:25 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 08:51:25 -0000 Received: by obfk16 with SMTP id k16so9130305obf.30 for ; Sun, 06 May 2012 01:51:24 -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=09ky27x81dl1OWxb/+i6b+OxXjqYpq0V7XsFRk7c/V0=; b=JBhNI1Qq5R6eN4IdCyr2sTNnIp3pNPgDvQ8VvANFtD3YCtLIil4Is40Ry5FdDzp+Ky vxfgxzmdHmPGunqVdRXLBSQ/dphOTIcCWL8JuMqU2EowzBfeVXgIT920JCjV+ZpjQLcs J02oWzWT9RIgRB0wAcxsFJHKmmbURxmJZSpUtFghTs1WZBIN29xXESqlyS8mu8hlt86S Q7O7klNfHvJdOJvZTWuOIxOjBrfsJDY9po5h1xT2ImvFAFsWzYNdpIAIE8tUs4I41DdR a81FmQUUJkMBh5vgv9lXCvIMWtx+7YLgwrpHUfIzEbhV7hGZhPAiAKWaU26QssY+GJK/ H+7w== MIME-Version: 1.0 Received: by 10.50.149.132 with SMTP id ua4mr6267094igb.41.1336294284255; Sun, 06 May 2012 01:51:24 -0700 (PDT) Received: by 10.50.100.198 with HTTP; Sun, 6 May 2012 01:51:24 -0700 (PDT) In-Reply-To: References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> Date: Sun, 6 May 2012 09:51:24 +0100 Message-ID: From: Peter Maydell To: Anup Patel X-Gm-Message-State: ALoCoQlkF2Ms7NJfrKs80fLOO0GzOVVZX8lQ2qm8Rl9Ii78mmZRV+QqRxvXGLyHQsmzmEygJsfb6 X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Marc Zyngier , "xen-arm@lists.xensource.com" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On 6 May 2012 05:22, Anup Patel wrote: > Also can you give example of a code sequence which is faster on model and > slower in real world. As far as I know ARM fast models are internally TLM > based models and If a TLM based model is emulating a timer chip of X clock > then it is quite precise X clock. Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour). You might want to read the Fast Models documentation, which tries to be clear about what the models do and don't provide. In particular: http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html "Fast models cannot be used to: * model cycle counting * model software performance " > Ofcourse CPU emulation and computation > power will be less compared to real world. To see this behaviour try to boot > linux on Fast model or QEMU and leave it for hours and come back see the > time elapsed, you will definitely see same amount of time elapsed as real > world. Nobody's arguing that the models are faster than hardware! Let's try a simple example with some numbers representing relative speeds: operation A: h/w: 1 ; model 5 operation B: h/w 3 ; model 30 Where we're comparing two equivalent code sequences "A A A A" vs "B". On hardware "B" will be faster. On the model the "A A A A" beats "B". (both sequences are slower on the model than on the hardware, obviously.) The point is that some operations will be vastly vastly slower on the model, and some operations merely moderately slower. Which of any two code sequences is fastest depends at least as much on whether it's using operations that are disproportionally worse on the model. A trivial example of this is VFP -- certainly QEMU has to do complex software emulation of the floating point ops to maintain bit-for-bit accuracy, which makes them very slow to the point where a hand-optimised-integer-assembly codec is likely to be faster on the model than a Neon/VFP-using codec, even though of course the Neon codec will be faster on hardware. [NB: this is itself a big simplification: model performance will depend on a lot of interacting things and is not purely a same-every-time slowdown per operation. Some operations effectively slow down what happens after them, for instance on QEMU if you do something that makes us flush our cache of translated code. And if for instance you have a periodic timer then the fact the model is generally slower means you execute proportionally more insns in the timer interrupt, so inefficiency or slowness in that code path has disproportionately more effect on overall speed than it does on hardware. There are other complications too...] > The results in the announcemnt are not baseless we have quite amount reasons > to believe Xvisor ARM will perform better than KVM ARM in real-world too. I'm not stating a position on whether KVM will be better or worse than Xvisor. I'm just pointing out that you can't base an argument on the faulty assumption that performance inside a model can tell you anything useful about performance on hardware. -- PMM _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWy-0006jh-VY; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQuKT-0006Gd-JC for xen-arm@lists.xen.org; Sun, 06 May 2012 05:48:21 +0000 Received: from [85.158.138.51:4031] by server-5.bemta-3.messagelabs.com id FB/5B-17113-4A016AF4; Sun, 06 May 2012 05:48:20 +0000 X-Env-Sender: hschauhan@nulltrace.org X-Msg-Ref: server-6.tower-174.messagelabs.com!1336283296!19443023!1 X-Originating-IP: [209.85.160.169] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6854 invoked from network); 6 May 2012 05:48:19 -0000 Received: from mail-gh0-f169.google.com (HELO mail-gy0-f169.google.com) (209.85.160.169) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 05:48:19 -0000 Received: by ghrr18 with SMTP id r18so3736873ghr.28 for ; Sat, 05 May 2012 22:48:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=uVY1tP0ul+KugJvNBoQGdLkFeSVFbOWTregpXiz0RVI=; b=oSqvn8jzQXgPHSSJ+dR2HKmUjJekxhwUhqXjwEbUQGxIPlAUoEJboXVaImKlbEenq4 Cjwb1BWby0oIuNTokO5Sp7i96kxZddCMcxeYgfNNakyMNhIEiD8xEPefCXdBItsNp5NB Zqnewh5tJlVhDBKPfad/chNYkmSPodEXgr1oimljervOZPI/l4uBzJmWGc3u2HQkYCHq 8sOBUAiVDW5vnGwfswPHOrSCvXYh5oI44hTUk46DMtnVkoR4KksrreZwCfjB5wZDMxEK ZeS752qf+GGAD/9UDi8s6FawBPvPumGZOP2fEtHE8IaHu/uknY6Pgzjrgq/lU/KR7xI4 gQHw== Received: by 10.236.181.42 with SMTP id k30mr4571202yhm.42.1336283296333; Sat, 05 May 2012 22:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.123.6 with HTTP; Sat, 5 May 2012 22:47:35 -0700 (PDT) X-Originating-IP: [122.167.110.121] In-Reply-To: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> References: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> From: "Chauhan, Himanshu" Date: Sun, 6 May 2012 11:17:35 +0530 Message-ID: To: xvisor-devel@googlegroups.com X-Gm-Message-State: ALoCoQnxCG1B7FN8PSk/tkbfFQRjAe2Gelj8kQk/zwM7pjDluXu7uvq6ANwoPBB4ldfKMLnrZlko X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: "xen-arm@lists.xen.org" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" , Peter Maydell Subject: Re: [XenARM] [xvisor-devel] Re: [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8845020324005984930==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============8845020324005984930== Content-Type: multipart/alternative; boundary=20cf305b0f9a32802204bf57b3d3 --20cf305b0f9a32802204bf57b3d3 Content-Type: text/plain; charset=ISO-8859-1 > The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. > > On the Fast Model. > > To quote from ARM site: "the Fast Models can help developers debug, analyze, and __optimize__ their applications throughout the development cycle." If fast models are not as is (which I understand they don't represent the microarchitecture), why care about optimizations in fast model then? I believe if X-Visor wins on fast model on what ever reasons, it WILL win on hardware as well. We must accept this. = Himanshu = --20cf305b0f9a32802204bf57b3d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > The previous announcement only proves that Xvisor ARM is relatively be= tter than KVM ARM.

On the Fast Model.

To quote from ARM site:

"the Fast Models= can help developers debug, analyze, and __optimize__ their applications th= roughout the development cycle."

If fast models are not as is (= which I understand they don't represent the microarchitecture), why car= e about optimizations in fast model then?

I believe if X-Visor wins on fast model on what ever reasons, it WILL w= in on hardware as well. We must accept this.

=3D Himanshu =3D

--20cf305b0f9a32802204bf57b3d3-- --===============8845020324005984930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============8845020324005984930==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWy-0006jO-NO; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQgh1-0005d2-8S for xen-arm@lists.xen.org; Sat, 05 May 2012 15:14:43 +0000 Received: from [193.109.254.147:64710] by server-10.bemta-14.messagelabs.com id 04/87-05847-2E345AF4; Sat, 05 May 2012 15:14:42 +0000 X-Env-Sender: marc.zyngier@arm.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1336230882!7793157!1 X-Originating-IP: [91.220.42.44] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDIxNzM4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3267 invoked from network); 5 May 2012 15:14:42 -0000 Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by server-13.tower-27.messagelabs.com with SMTP; 5 May 2012 15:14:42 -0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Sat, 05 May 2012 16:14:41 +0100 Received: from taxman.wild-wind.fr.eu.org ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 May 2012 16:16:12 +0100 Date: Sat, 5 May 2012 16:14:36 +0100 From: Marc Zyngier To: Anup Patel Message-ID: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> In-Reply-To: References: Organization: ARM Ltd X-Mailer: Claws Mail 3.8.0 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-OriginalArrivalTime: 05 May 2012 15:16:12.0592 (UTC) FILETIME=[01D61B00:01CD2AD2] X-MC-Unique: 112050516144100201 X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Sat, 5 May 2012 15:31:36 +0100 Anup Patel wrote: > Hi PMM, > > Also in my-view even if we have in-kernel emulation of irqchip and timer still Xvisor ARM will be performing better than KVM ARM because amount of code path traversed in KVM ARM will always be more. > > (Please note my-view about in-kernel emulation is totally based on code flow comparison of Xvisor ARM emulation and possible KVM ARM in-kernel emulation) > Sweet. Can I borrow your crystal ball? M. > On Sat, May 5, 2012 at 7:54 PM, Anup Patel > wrote: > Hi PMM, > > I agree we cannot predict real world performance based on performance on ARM fast models but if system A is performing better than system B no ARM fast model or QEMU then in real world system A will perform better than system B. Of-course in real world scale of difference in performance between system A and system B will differ. > > The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. > > Regards, > --Anup > > > On Sat, May 5, 2012 at 3:36 PM, Peter Maydell > wrote: > 2012/5/5 Anup Patel >: > > This announcement is to show an apple to apple performance comparison > > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. > > I would strongly caution against trying to do any performance/timing > type tests if you're still running on the ARM Fast Model -- they are > not representative of performance characteristics on hardware > and you really can't draw any conclusions about real world > performance by timing things on a model. It's quite easy to get > into a situation where all you're measuring is "does my code happen > to do a lot of some perfectly reasonable operation which happens > to be hard and slow to implement for the model?". > > (Also, KVM for ARM is still under development and we haven't > yet made several of the obvious performance improvements like > in-kernel irqchip and timer support, so it's not really a very > useful thing to compare against yet.) > > -- PMM > > -- I'm the slime oozin' out from your TV set... _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWz-0006js-56; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxBh-0007qe-1o for xen-arm@lists.xen.org; Sun, 06 May 2012 08:51:29 +0000 Received: from [85.158.143.99:4991] by server-3.bemta-4.messagelabs.com id 47/6A-05853-09B36AF4; Sun, 06 May 2012 08:51:28 +0000 X-Env-Sender: peter.maydell@linaro.org X-Msg-Ref: server-5.tower-216.messagelabs.com!1336294284!26359698!1 X-Originating-IP: [209.85.214.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16653 invoked from network); 6 May 2012 08:51:26 -0000 Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 08:51:26 -0000 Received: by obbwd20 with SMTP id wd20so8702922obb.32 for ; Sun, 06 May 2012 01:51:24 -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=09ky27x81dl1OWxb/+i6b+OxXjqYpq0V7XsFRk7c/V0=; b=bI276hS2K77GSziooXGqrqKE2t65Z5qRTymTUMaGmwkWAIDyOL/p8rPaB2POy8UrLA r6czHcnOpQPLLD6ZTetr+WCngo5adDViuc3XRV2HgEyUYWAuaU9vZlHtc2FRRMDiL/Ru TLykAf5h2bs4qwwxiork3qZPilj1s7lXRoXfxh6M25+VzAsRd38enOne7rik3Ap1i+9K vDSxUKlboao3MEYF4AMKv9Fc5Cn0+hlS9v6AylAkD3p6xDkl7+iwPyjAH+J5ui7vpo/x KcT+lqnBZ42YfCU7/8TzSacEohuPvS1nHlFXFT0jrDS0iBdd9DHzh9b8x3Dsd8JOMR95 4mVg== MIME-Version: 1.0 Received: by 10.50.149.132 with SMTP id ua4mr6267094igb.41.1336294284255; Sun, 06 May 2012 01:51:24 -0700 (PDT) Received: by 10.50.100.198 with HTTP; Sun, 6 May 2012 01:51:24 -0700 (PDT) In-Reply-To: References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> Date: Sun, 6 May 2012 09:51:24 +0100 Message-ID: From: Peter Maydell To: Anup Patel X-Gm-Message-State: ALoCoQk44PlWaJOx3Alk1HqgAgy1vglBIrNq2ZJ+2FJDE6VR+FEMvOqzcZ/zajsrIrZQDneuZxFt X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Marc Zyngier , "xen-arm@lists.xensource.com" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On 6 May 2012 05:22, Anup Patel wrote: > Also can you give example of a code sequence which is faster on model and > slower in real world. As far as I know ARM fast models are internally TLM > based models and If a TLM based model is emulating a timer chip of X clock > then it is quite precise X clock. Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour). You might want to read the Fast Models documentation, which tries to be clear about what the models do and don't provide. In particular: http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html "Fast models cannot be used to: * model cycle counting * model software performance " > Ofcourse CPU emulation and computation > power will be less compared to real world. To see this behaviour try to boot > linux on Fast model or QEMU and leave it for hours and come back see the > time elapsed, you will definitely see same amount of time elapsed as real > world. Nobody's arguing that the models are faster than hardware! Let's try a simple example with some numbers representing relative speeds: operation A: h/w: 1 ; model 5 operation B: h/w 3 ; model 30 Where we're comparing two equivalent code sequences "A A A A" vs "B". On hardware "B" will be faster. On the model the "A A A A" beats "B". (both sequences are slower on the model than on the hardware, obviously.) The point is that some operations will be vastly vastly slower on the model, and some operations merely moderately slower. Which of any two code sequences is fastest depends at least as much on whether it's using operations that are disproportionally worse on the model. A trivial example of this is VFP -- certainly QEMU has to do complex software emulation of the floating point ops to maintain bit-for-bit accuracy, which makes them very slow to the point where a hand-optimised-integer-assembly codec is likely to be faster on the model than a Neon/VFP-using codec, even though of course the Neon codec will be faster on hardware. [NB: this is itself a big simplification: model performance will depend on a lot of interacting things and is not purely a same-every-time slowdown per operation. Some operations effectively slow down what happens after them, for instance on QEMU if you do something that makes us flush our cache of translated code. And if for instance you have a periodic timer then the fact the model is generally slower means you execute proportionally more insns in the timer interrupt, so inefficiency or slowness in that code path has disproportionately more effect on overall speed than it does on hardware. There are other complications too...] > The results in the announcemnt are not baseless we have quite amount reasons > to believe Xvisor ARM will perform better than KVM ARM in real-world too. I'm not stating a position on whether KVM will be better or worse than Xvisor. I'm just pointing out that you can't base an argument on the faulty assumption that performance inside a model can tell you anything useful about performance on hardware. -- PMM _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWy-0006jO-NO; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQgh1-0005d2-8S for xen-arm@lists.xen.org; Sat, 05 May 2012 15:14:43 +0000 Received: from [193.109.254.147:64710] by server-10.bemta-14.messagelabs.com id 04/87-05847-2E345AF4; Sat, 05 May 2012 15:14:42 +0000 X-Env-Sender: marc.zyngier@arm.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1336230882!7793157!1 X-Originating-IP: [91.220.42.44] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDIxNzM4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3267 invoked from network); 5 May 2012 15:14:42 -0000 Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by server-13.tower-27.messagelabs.com with SMTP; 5 May 2012 15:14:42 -0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Sat, 05 May 2012 16:14:41 +0100 Received: from taxman.wild-wind.fr.eu.org ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 May 2012 16:16:12 +0100 Date: Sat, 5 May 2012 16:14:36 +0100 From: Marc Zyngier To: Anup Patel Message-ID: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> In-Reply-To: References: Organization: ARM Ltd X-Mailer: Claws Mail 3.8.0 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-OriginalArrivalTime: 05 May 2012 15:16:12.0592 (UTC) FILETIME=[01D61B00:01CD2AD2] X-MC-Unique: 112050516144100201 X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Sat, 5 May 2012 15:31:36 +0100 Anup Patel wrote: > Hi PMM, > > Also in my-view even if we have in-kernel emulation of irqchip and timer still Xvisor ARM will be performing better than KVM ARM because amount of code path traversed in KVM ARM will always be more. > > (Please note my-view about in-kernel emulation is totally based on code flow comparison of Xvisor ARM emulation and possible KVM ARM in-kernel emulation) > Sweet. Can I borrow your crystal ball? M. > On Sat, May 5, 2012 at 7:54 PM, Anup Patel > wrote: > Hi PMM, > > I agree we cannot predict real world performance based on performance on ARM fast models but if system A is performing better than system B no ARM fast model or QEMU then in real world system A will perform better than system B. Of-course in real world scale of difference in performance between system A and system B will differ. > > The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. > > Regards, > --Anup > > > On Sat, May 5, 2012 at 3:36 PM, Peter Maydell > wrote: > 2012/5/5 Anup Patel >: > > This announcement is to show an apple to apple performance comparison > > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. > > I would strongly caution against trying to do any performance/timing > type tests if you're still running on the ARM Fast Model -- they are > not representative of performance characteristics on hardware > and you really can't draw any conclusions about real world > performance by timing things on a model. It's quite easy to get > into a situation where all you're measuring is "does my code happen > to do a lot of some perfectly reasonable operation which happens > to be hard and slow to implement for the model?". > > (Also, KVM for ARM is still under development and we haven't > yet made several of the obvious performance improvements like > in-kernel irqchip and timer support, so it's not really a very > useful thing to compare against yet.) > > -- PMM > > -- I'm the slime oozin' out from your TV set... _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14:57: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 1SWqWz-0006js-56; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxBh-0007qe-1o for xen-arm@lists.xen.org; Sun, 06 May 2012 08:51:29 +0000 Received: from [85.158.143.99:4991] by server-3.bemta-4.messagelabs.com id 47/6A-05853-09B36AF4; Sun, 06 May 2012 08:51:28 +0000 X-Env-Sender: peter.maydell@linaro.org X-Msg-Ref: server-5.tower-216.messagelabs.com!1336294284!26359698!1 X-Originating-IP: [209.85.214.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16653 invoked from network); 6 May 2012 08:51:26 -0000 Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 08:51:26 -0000 Received: by obbwd20 with SMTP id wd20so8702922obb.32 for ; Sun, 06 May 2012 01:51:24 -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=09ky27x81dl1OWxb/+i6b+OxXjqYpq0V7XsFRk7c/V0=; b=bI276hS2K77GSziooXGqrqKE2t65Z5qRTymTUMaGmwkWAIDyOL/p8rPaB2POy8UrLA r6czHcnOpQPLLD6ZTetr+WCngo5adDViuc3XRV2HgEyUYWAuaU9vZlHtc2FRRMDiL/Ru TLykAf5h2bs4qwwxiork3qZPilj1s7lXRoXfxh6M25+VzAsRd38enOne7rik3Ap1i+9K vDSxUKlboao3MEYF4AMKv9Fc5Cn0+hlS9v6AylAkD3p6xDkl7+iwPyjAH+J5ui7vpo/x KcT+lqnBZ42YfCU7/8TzSacEohuPvS1nHlFXFT0jrDS0iBdd9DHzh9b8x3Dsd8JOMR95 4mVg== MIME-Version: 1.0 Received: by 10.50.149.132 with SMTP id ua4mr6267094igb.41.1336294284255; Sun, 06 May 2012 01:51:24 -0700 (PDT) Received: by 10.50.100.198 with HTTP; Sun, 6 May 2012 01:51:24 -0700 (PDT) In-Reply-To: References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> Date: Sun, 6 May 2012 09:51:24 +0100 Message-ID: From: Peter Maydell To: Anup Patel X-Gm-Message-State: ALoCoQk44PlWaJOx3Alk1HqgAgy1vglBIrNq2ZJ+2FJDE6VR+FEMvOqzcZ/zajsrIrZQDneuZxFt X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Marc Zyngier , "xen-arm@lists.xensource.com" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On 6 May 2012 05:22, Anup Patel wrote: > Also can you give example of a code sequence which is faster on model and > slower in real world. As far as I know ARM fast models are internally TLM > based models and If a TLM based model is emulating a timer chip of X clock > then it is quite precise X clock. Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour). You might want to read the Fast Models documentation, which tries to be clear about what the models do and don't provide. In particular: http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html "Fast models cannot be used to: * model cycle counting * model software performance " > Ofcourse CPU emulation and computation > power will be less compared to real world. To see this behaviour try to boot > linux on Fast model or QEMU and leave it for hours and come back see the > time elapsed, you will definitely see same amount of time elapsed as real > world. Nobody's arguing that the models are faster than hardware! Let's try a simple example with some numbers representing relative speeds: operation A: h/w: 1 ; model 5 operation B: h/w 3 ; model 30 Where we're comparing two equivalent code sequences "A A A A" vs "B". On hardware "B" will be faster. On the model the "A A A A" beats "B". (both sequences are slower on the model than on the hardware, obviously.) The point is that some operations will be vastly vastly slower on the model, and some operations merely moderately slower. Which of any two code sequences is fastest depends at least as much on whether it's using operations that are disproportionally worse on the model. A trivial example of this is VFP -- certainly QEMU has to do complex software emulation of the floating point ops to maintain bit-for-bit accuracy, which makes them very slow to the point where a hand-optimised-integer-assembly codec is likely to be faster on the model than a Neon/VFP-using codec, even though of course the Neon codec will be faster on hardware. [NB: this is itself a big simplification: model performance will depend on a lot of interacting things and is not purely a same-every-time slowdown per operation. Some operations effectively slow down what happens after them, for instance on QEMU if you do something that makes us flush our cache of translated code. And if for instance you have a periodic timer then the fact the model is generally slower means you execute proportionally more insns in the timer interrupt, so inefficiency or slowness in that code path has disproportionately more effect on overall speed than it does on hardware. There are other complications too...] > The results in the announcemnt are not baseless we have quite amount reasons > to believe Xvisor ARM will perform better than KVM ARM in real-world too. I'm not stating a position on whether KVM will be better or worse than Xvisor. I'm just pointing out that you can't base an argument on the faulty assumption that performance inside a model can tell you anything useful about performance on hardware. -- PMM _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWz-0006kY-JU; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4lw-0001pF-4p for xen-arm@lists.xensource.com; Wed, 09 May 2012 11:09:32 +0000 Received: from [85.158.143.99:62736] by server-2.bemta-4.messagelabs.com id 3C/74-17550-A605AAF4; Wed, 09 May 2012 11:09:30 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-9.tower-216.messagelabs.com!1336561766!27185299!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2302 invoked from network); 9 May 2012 11:09:28 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:09:28 -0000 Received: by vbbfq11 with SMTP id fq11so205993vbb.30 for ; Wed, 09 May 2012 04:09:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Iip9unawQeOcSC76fLUnbwyIhGYIcbxrJEMwS+RW1uM=; b=IcxFv9LUTqsCEXvUPQvKyJ4UCl6VbpuTte4C++Fh6j0D0FSWMLU34qDOqKtwV5eCtY NRG0CftMxdUS91vHRR+I98wL8JTo1KwlHxUmGdWjaVUtEwGGU35KenKDGPPZXsQZcnyN R/liOP7IHNRoIlEQXoNAYYTI/oMh8Nc8I2Z1K0gmJCETuEi6dTOfRJuL9lfx6hcn2IOc Y68qOne8FoB1EuVfGVYZZEZhLLanGUTdKcwHH/HSCXwcjww4S0SGcEdB91PB3rbiz1U5 bOECWsbmiRil62y8uve9PNwGZoycGW76uL4EmTzdVjj3/yt6QnHvkhy5jDVnRUv42wys Olww== Received: by 10.52.34.79 with SMTP id x15mr10532740vdi.0.1336561766655; Wed, 09 May 2012 04:09:26 -0700 (PDT) References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> <-3890923700307571348@unknownmsgid> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Wed, 9 May 2012 07:09:22 -0400 Message-ID: <5386794781075909369@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQnvYyJgU4e0cKeGwHOuy9R3rRpDs8FueYG4L1M5r7DlBP0V7RjTdczQSM3K++P0Z8t02JxH X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Christoffer Dall , Peter Maydell , "xen-arm@lists.xensource.com" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" , Xvisor Devel Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8553920838609294694==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============8553920838609294694== Content-Type: multipart/alternative; boundary=20cf3079b82652666904bf98898f --20cf3079b82652666904bf98898f Content-Type: text/plain; charset=ISO-8859-1 On May 9, 2012, at 2:11 AM, Anup Patel wrote: The intention behind the announcement was to inform people interested in virtualization about Xvisor. consider the members og this list informed. The announcement was an early info about achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planning to have scientific paper for Xvisor. Also, I do agree that KVM ARM can be further optimized but as I mentioned in my previous replies "KVM ARM will end-up putting more and more stuff in-kernel". For now you can think of Xvisor ARM = KVM ARM doing everything in-kernel. Even Xvisor ARM is being optimized so, as time passes Xvisor ARM is also going to improve further. Its a common wisdom that "No hypervisor in the world can be better than Native performance". Xvisor ARM is already very very close to native performance and KVM ARM will come close to native performance only by increasing its monolithic nature (i.e. doing more things in-kernel). If monolithic hypervisors are so well performing then why not to have a monolithic hypervisor made for virtualization purpose only. The motivation behind writing Xvisor was the same. Apart from high performance Xvisor has many interesting features such as: *Ability to work without hardware virtualization support* - Xvisor ARM is able to boot multiple unmodified Linux guest even on hosts which do not have virtualization extensions implemented. In contrast, KVM ARM does not work without virtualization extension. The potential number of host hardware that Xvisor ARM can support is much more than KVM ARM can support. Xvisor ARM can in-fact run on old ARMv5 processors too. *Tree-based configuration* - To create a guest we have to just describe the guest in form of a device tree (possible even in runtime). In contrast, for KVM one needs to add the support in QEMU and recompile the binaries. *Pass-through hardware access* - For hardware not accessed or virtualized by Xvisor can be used in pass-through mode. Providing the guests a pass-through accessible device is just matter of adding a tree node and configure irq routing information in guest tree. Its not just PCI devices, we can provide any kind of device as pass-through accessible (Note: if device has in-built DMA then it should have IOMMU or SysMMU otherwise it would be security breach). We have already tried out Serial Port and NIC as pass-through devices. We can compare KVM advantages with Xvisor as follows: *Scheduler* - The linux kernel scheduler is very mature and proven OS scheduler but Hypervisor scheduler can be quite different. Scheduling processes and scheduling VMs can be very different problems. In case of VMs we can use info such as: amount of emulated IO done, amount of time spend in waiting for irq, etc for improving the quality of server consolidation. *Driver base* - Xvisor has and will have all driver framework APIs similar to Linux and driver porting will be just one-on-one replacement of APIs in most cases. *User space tools* - For starter Xvisor will use libvirt tools (or similar open source initiative) for remote management. *Co-existence host processes* - Xvisor is not an OS. Its made for virtualization only so no process. Ofcourse, Xvisor has internal threading framework but most of the time this background threads are sleeping doing nothing. All the management commands are provided by --Anup On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall wrote: > Anup, > > Thanks for providing info on your Xvisor project. However, this is a > mailing list for the development of KVM/ARM and not a scientific forum to > establish in theory which hypervisor "will always perform better than" > which other hypervisor. > > If you want to establish that your code base will always perform better > than all other hosted hypervisors, I strongly encourage you to submit a > paper about this in a peer reviewed conference. Personally I would find > that establishing such facts in a scientific way to be extremely > interesting. > > I understand that you wish to argue Xvisor's superiority in comparison to > KVM, but I disagree with your conclusions. The code path taken in KVM can > be optimized to be extremely short and all logic could be placed within the > KVM module. There are numerous other advantages to using KVM (existing > driver base, upstream kernel integration, compatibility with existing user > space tools, co-existence with native host processes, etc.) and with server > grade hardware I see the reliance on the Linux kernel for scheduling, > memory management etc. to be a great advantage - and not a drawback. On the > other hand, when Xvisor matures, feature requests will only increase its > code size and complexity as well. > > -Christoffer > > On May 6, 2012, at 7:53 AM, Anup Patel wrote: > > Hi PMM, > > Whether to consider model for measuring performance is one's own opinion. > There are number of Tier1 conferences which accept simulation numbers for > proving better approaches provided the simulation platform is well accepted > by everyone. > > Talking about code sequences both Xvisor ARM and KVM ARM have same set of > emulators and drivers. In fact, almost all emulation code has been adopted > from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike > KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to > guest mode and amount of code traversed in handling any fault is also very > less hence Xvisor-ARM will have much less code executed compared to KVM ARM. > > In Xvisor developement, we have observed that results of any CPU > performance test on QEMU or Fast Model naturally scales up on > real-hardware. Atleast we have never come across any scenario or test > performing better on QEMU or Fast Model compared real-world (this is true > for test running on Native Linux or Linux running as guest on Xvisor ARM). > > In our opinion we strongly believe monolithic approaches are always better > performing over micro-kernelized approaches (or approaches somewhere in > between micro-kernel and monolithic). Hence Xvisor ARM will always perform > better than KVM ARM in theory, simulation and real-world. > > Best Regards, > Anup Patel > > On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > >> On 6 May 2012 05:22, Anup Patel wrote: >> > Also can you give example of a code sequence which is faster on model >> and >> > slower in real world. As far as I know ARM fast models are internally >> TLM >> > based models and If a TLM based model is emulating a timer chip of X >> clock >> > then it is quite precise X clock. >> >> Support for TLM does not require that the underlying model is cycle >> accurate (you can have 'loosely timed' behaviour). >> >> You might want to read the Fast Models documentation, which tries >> to be clear about what the models do and don't provide. In particular: >> >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html >> "Fast models cannot be used to: >> * model cycle counting >> * model software performance >> " >> >> > Ofcourse CPU emulation and computation >> > power will be less compared to real world. To see this behaviour try to >> boot >> > linux on Fast model or QEMU and leave it for hours and come back see the >> > time elapsed, you will definitely see same amount of time elapsed as >> real >> > world. >> >> Nobody's arguing that the models are faster than hardware! >> Let's try a simple example with some numbers representing >> relative speeds: >> >> operation A: h/w: 1 ; model 5 >> operation B: h/w 3 ; model 30 >> >> Where we're comparing two equivalent code sequences "A A A A" vs "B". >> On hardware "B" will be faster. On the model the "A A A A" beats "B". >> (both sequences are slower on the model than on the hardware, obviously.) >> >> The point is that some operations will be vastly vastly slower >> on the model, and some operations merely moderately slower. Which >> of any two code sequences is fastest depends at least as much on >> whether it's using operations that are disproportionally worse >> on the model. A trivial example of this is VFP -- certainly QEMU >> has to do complex software emulation of the floating point ops to >> maintain bit-for-bit accuracy, which makes them very slow to the >> point where a hand-optimised-integer-assembly codec is likely to >> be faster on the model than a Neon/VFP-using codec, even though >> of course the Neon codec will be faster on hardware. >> >> [NB: this is itself a big simplification: model performance will >> depend on a lot of interacting things and is not purely a >> same-every-time slowdown per operation. Some operations effectively >> slow down what happens after them, for instance on QEMU if you do >> something that makes us flush our cache of translated code. And >> if for instance you have a periodic timer then the fact the model >> is generally slower means you execute proportionally more insns in >> the timer interrupt, so inefficiency or slowness in that code path >> has disproportionately more effect on overall speed than it does >> on hardware. There are other complications too...] >> >> > The results in the announcemnt are not baseless we have quite amount >> reasons >> > to believe Xvisor ARM will perform better than KVM ARM in real-world >> too. >> >> I'm not stating a position on whether KVM will be better or worse >> than Xvisor. I'm just pointing out that you can't base an argument >> on the faulty assumption that performance inside a model can tell >> you anything useful about performance on hardware. >> >> -- PMM >> > > _______________________________________________ > Android-virt mailing list > Android-virt@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > > --20cf3079b82652666904bf98898f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On May 9, 2012, at 2:11 AM, Anup Patel <anup@brainfault.org> wrote:

The intention behind the announcement = was to inform people interested in virtualization about Xvisor.

consider the members og this list informed.=A0
The announcement was an early info about= achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are= planning to have scientific paper for Xvisor.

Also, I do agree that KVM ARM can be further optimized but as I mention= ed in my previous replies "KVM ARM will end-up putting more and more s= tuff in-kernel". For now you can think of Xvisor ARM =3D KVM ARM doing= everything in-kernel. Even Xvisor ARM is being optimized so, as time passe= s Xvisor ARM is also going to improve further. Its a common wisdom that &qu= ot;No hypervisor in the world can be better than Native performance". = Xvisor ARM is already very very close to native performance and KVM ARM wil= l come close to native performance only by increasing its monolithic nature= (i.e. doing more things in-kernel). If monolithic hypervisors are so well = performing then why not to have a monolithic hypervisor made for virtualiza= tion purpose only. The motivation behind writing Xvisor was the same.

Apart from high performance Xvisor has many interesting features such a= s:
Ability to work without hardware virtualization support - Xvis= or ARM is able to boot multiple unmodified Linux guest even on hosts which = do not have virtualization extensions implemented. In contrast, KVM ARM doe= s not work without virtualization extension. The potential number of host h= ardware that Xvisor ARM can support is much more than KVM ARM can support. = Xvisor ARM can in-fact run on old ARMv5 processors too.
Tree-based configuration - To create a guest we have to just describ= e the guest in form of a device tree (possible even in runtime). In contras= t, for KVM one needs to add the support in QEMU and recompile the binaries.=
Pass-through hardware access - For hardware not accessed or virtuali= zed by Xvisor can be used in pass-through mode. Providing the guests a pass= -through accessible device is just matter of adding a tree node and configu= re irq routing information in guest tree. Its not just PCI devices, we can = provide any kind of device as pass-through accessible (Note: if device has = in-built DMA then it should have IOMMU or SysMMU otherwise it would be secu= rity breach). We have already tried out Serial Port and NIC as pass-through= devices.

We can compare KVM advantages with Xvisor as follows:
Scheduler - The linux kernel scheduler is very mature and proven OS scheduler but = Hypervisor scheduler can be quite different. Scheduling processes and sched= uling VMs can be very different problems. In case of VMs we can use info su= ch as: amount of emulated IO done, amount of time spend in waiting for irq,= etc for improving the quality of server consolidation.
Driver base - Xvisor has and will have all driver framework APIs sim= ilar to Linux and driver porting will be just one-on-one replacement of API= s in most cases.
User space tools - For starter Xvisor will use = libvirt tools (or similar open source initiative) for remote management. Co-existence host processes - Xvisor is not an OS. Its made for virt= ualization only so no process. Ofcourse, Xvisor has internal threading fram= ework but most of the time this background threads are sleeping doing nothi= ng. All the management commands are provided by=A0

--Anup

On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall <= cdall@cs.columbia.edu> wrote:

Anup,

Thanks for pro= viding info on your Xvisor project. However, this is a mailing list for the= development of KVM/ARM and not a scientific forum to establish in theory w= hich hypervisor "will always perform better than" which oth= er hypervisor.

If you want to establish that your c= ode base will always perform better than all other hosted hypervisors, I st= rongly encourage you to submit a paper about this in a peer reviewed confer= ence. Personally I would find that establishing such facts in a scientific = way to be extremely interesting.=A0

I understand that you w= ish to argue Xvisor's superiority in comparison to KVM, but I disagree = with your conclusions. The code path taken in KVM can be optimized to be ex= tremely short and all logic could be placed within the KVM module. There ar= e numerous other advantages to using KVM (existing driver base, upstream ke= rnel integration, compatibility with existing user space tools, co-existenc= e with native host processes, etc.) and with server grade hardware I see th= e reliance on the Linux kernel for scheduling, memory management etc. to be= a great advantage - and not a drawback. On the other hand, when Xvisor mat= ures, feature requests will only increase its code size and complexity as w= ell.

-Christoffer

On May 6, 2012, at 7:53 AM, Anup Patel <anup@brainfault.org> w= rote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup Patel <anup@brainfault.org> wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0 http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

_______= ________________________________________
Android-virt maili= ng list
Android-virt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/and= roid-virt

--20cf3079b82652666904bf98898f-- --===============8553920838609294694== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============8553920838609294694==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWy-0006j1-Cq; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQbsk-0003rC-Fy for xen-arm@lists.xensource.com; Sat, 05 May 2012 10:06:30 +0000 Received: from [193.109.254.147:34257] by server-8.bemta-14.messagelabs.com id A4/8A-23244-5ABF4AF4; Sat, 05 May 2012 10:06:29 +0000 X-Env-Sender: peter.maydell@linaro.org X-Msg-Ref: server-7.tower-27.messagelabs.com!1336212387!77010!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10010 invoked from network); 5 May 2012 10:06:29 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 10:06:29 -0000 Received: by obfk16 with SMTP id k16so7181115obf.30 for ; Sat, 05 May 2012 03:06:27 -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=sMZ4Wd0pTPl76B3K/zj9MZpmHlob7CHkply9MapD//A=; b=OZy1xPXaJGE0WEeD+Ft+3chGIdJ+KpK9iyGZWGbxWH8ob6Sd9WnXoPlO74MYmcng0W uIvvaJN9qmxUsiXV2qtHQMNBFJ/9mW+wQSH9V3+TeZTs8Zu5pu3swMKunxWeIq/m634A dormhX/zXn2laPTFiIAlDYZxktEYh/sGZlBY8zs7EQmHspvqZbBHMSmQlzjKWUY9l8Zn f7QSquzLEK/cl94MIQvXNGJqUrhl5RMyJ3yHuQo5znJY+AtUrYgYAZJibIzxD1VxCKVa bGuThFeXe5AFkwyByXRX0PVPSOqhkM2Vr2M8z5tIC3D1fR87p/T23jhIKYJK4auD+8W3 OzhQ== MIME-Version: 1.0 Received: by 10.50.188.138 with SMTP id ga10mr4779729igc.51.1336212387319; Sat, 05 May 2012 03:06:27 -0700 (PDT) Received: by 10.50.100.198 with HTTP; Sat, 5 May 2012 03:06:27 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 May 2012 11:06:27 +0100 Message-ID: From: Peter Maydell To: Anup Patel X-Gm-Message-State: ALoCoQl4N8O61MU4Oz1tHr8zwNsupCZRJUi3+4DcPy8ePEx+eInkNb4MK+lQF8FLqAkfhDC2MW5O X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: xen-arm@lists.xensource.com, Xvisor Devel , android-virt@lists.cs.columbia.edu, xen-arm@lists.xen.org Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org 2012/5/5 Anup Patel : > This announcement is to show an apple to apple performance comparison > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. I would strongly caution against trying to do any performance/timing type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware and you really can't draw any conclusions about real world performance by timing things on a model. It's quite easy to get into a situation where all you're measuring is "does my code happen to do a lot of some perfectly reasonable operation which happens to be hard and slow to implement for the model?". (Also, KVM for ARM is still under development and we haven't yet made several of the obvious performance improvements like in-kernel irqchip and timer support, so it's not really a very useful thing to compare against yet.) -- PMM _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWz-0006kY-JU; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4lw-0001pF-4p for xen-arm@lists.xensource.com; Wed, 09 May 2012 11:09:32 +0000 Received: from [85.158.143.99:62736] by server-2.bemta-4.messagelabs.com id 3C/74-17550-A605AAF4; Wed, 09 May 2012 11:09:30 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-9.tower-216.messagelabs.com!1336561766!27185299!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2302 invoked from network); 9 May 2012 11:09:28 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:09:28 -0000 Received: by vbbfq11 with SMTP id fq11so205993vbb.30 for ; Wed, 09 May 2012 04:09:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Iip9unawQeOcSC76fLUnbwyIhGYIcbxrJEMwS+RW1uM=; b=IcxFv9LUTqsCEXvUPQvKyJ4UCl6VbpuTte4C++Fh6j0D0FSWMLU34qDOqKtwV5eCtY NRG0CftMxdUS91vHRR+I98wL8JTo1KwlHxUmGdWjaVUtEwGGU35KenKDGPPZXsQZcnyN R/liOP7IHNRoIlEQXoNAYYTI/oMh8Nc8I2Z1K0gmJCETuEi6dTOfRJuL9lfx6hcn2IOc Y68qOne8FoB1EuVfGVYZZEZhLLanGUTdKcwHH/HSCXwcjww4S0SGcEdB91PB3rbiz1U5 bOECWsbmiRil62y8uve9PNwGZoycGW76uL4EmTzdVjj3/yt6QnHvkhy5jDVnRUv42wys Olww== Received: by 10.52.34.79 with SMTP id x15mr10532740vdi.0.1336561766655; Wed, 09 May 2012 04:09:26 -0700 (PDT) References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> <-3890923700307571348@unknownmsgid> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Wed, 9 May 2012 07:09:22 -0400 Message-ID: <5386794781075909369@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQnvYyJgU4e0cKeGwHOuy9R3rRpDs8FueYG4L1M5r7DlBP0V7RjTdczQSM3K++P0Z8t02JxH X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Christoffer Dall , Peter Maydell , "xen-arm@lists.xensource.com" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" , Xvisor Devel Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8553920838609294694==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============8553920838609294694== Content-Type: multipart/alternative; boundary=20cf3079b82652666904bf98898f --20cf3079b82652666904bf98898f Content-Type: text/plain; charset=ISO-8859-1 On May 9, 2012, at 2:11 AM, Anup Patel wrote: The intention behind the announcement was to inform people interested in virtualization about Xvisor. consider the members og this list informed. The announcement was an early info about achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planning to have scientific paper for Xvisor. Also, I do agree that KVM ARM can be further optimized but as I mentioned in my previous replies "KVM ARM will end-up putting more and more stuff in-kernel". For now you can think of Xvisor ARM = KVM ARM doing everything in-kernel. Even Xvisor ARM is being optimized so, as time passes Xvisor ARM is also going to improve further. Its a common wisdom that "No hypervisor in the world can be better than Native performance". Xvisor ARM is already very very close to native performance and KVM ARM will come close to native performance only by increasing its monolithic nature (i.e. doing more things in-kernel). If monolithic hypervisors are so well performing then why not to have a monolithic hypervisor made for virtualization purpose only. The motivation behind writing Xvisor was the same. Apart from high performance Xvisor has many interesting features such as: *Ability to work without hardware virtualization support* - Xvisor ARM is able to boot multiple unmodified Linux guest even on hosts which do not have virtualization extensions implemented. In contrast, KVM ARM does not work without virtualization extension. The potential number of host hardware that Xvisor ARM can support is much more than KVM ARM can support. Xvisor ARM can in-fact run on old ARMv5 processors too. *Tree-based configuration* - To create a guest we have to just describe the guest in form of a device tree (possible even in runtime). In contrast, for KVM one needs to add the support in QEMU and recompile the binaries. *Pass-through hardware access* - For hardware not accessed or virtualized by Xvisor can be used in pass-through mode. Providing the guests a pass-through accessible device is just matter of adding a tree node and configure irq routing information in guest tree. Its not just PCI devices, we can provide any kind of device as pass-through accessible (Note: if device has in-built DMA then it should have IOMMU or SysMMU otherwise it would be security breach). We have already tried out Serial Port and NIC as pass-through devices. We can compare KVM advantages with Xvisor as follows: *Scheduler* - The linux kernel scheduler is very mature and proven OS scheduler but Hypervisor scheduler can be quite different. Scheduling processes and scheduling VMs can be very different problems. In case of VMs we can use info such as: amount of emulated IO done, amount of time spend in waiting for irq, etc for improving the quality of server consolidation. *Driver base* - Xvisor has and will have all driver framework APIs similar to Linux and driver porting will be just one-on-one replacement of APIs in most cases. *User space tools* - For starter Xvisor will use libvirt tools (or similar open source initiative) for remote management. *Co-existence host processes* - Xvisor is not an OS. Its made for virtualization only so no process. Ofcourse, Xvisor has internal threading framework but most of the time this background threads are sleeping doing nothing. All the management commands are provided by --Anup On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall wrote: > Anup, > > Thanks for providing info on your Xvisor project. However, this is a > mailing list for the development of KVM/ARM and not a scientific forum to > establish in theory which hypervisor "will always perform better than" > which other hypervisor. > > If you want to establish that your code base will always perform better > than all other hosted hypervisors, I strongly encourage you to submit a > paper about this in a peer reviewed conference. Personally I would find > that establishing such facts in a scientific way to be extremely > interesting. > > I understand that you wish to argue Xvisor's superiority in comparison to > KVM, but I disagree with your conclusions. The code path taken in KVM can > be optimized to be extremely short and all logic could be placed within the > KVM module. There are numerous other advantages to using KVM (existing > driver base, upstream kernel integration, compatibility with existing user > space tools, co-existence with native host processes, etc.) and with server > grade hardware I see the reliance on the Linux kernel for scheduling, > memory management etc. to be a great advantage - and not a drawback. On the > other hand, when Xvisor matures, feature requests will only increase its > code size and complexity as well. > > -Christoffer > > On May 6, 2012, at 7:53 AM, Anup Patel wrote: > > Hi PMM, > > Whether to consider model for measuring performance is one's own opinion. > There are number of Tier1 conferences which accept simulation numbers for > proving better approaches provided the simulation platform is well accepted > by everyone. > > Talking about code sequences both Xvisor ARM and KVM ARM have same set of > emulators and drivers. In fact, almost all emulation code has been adopted > from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike > KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to > guest mode and amount of code traversed in handling any fault is also very > less hence Xvisor-ARM will have much less code executed compared to KVM ARM. > > In Xvisor developement, we have observed that results of any CPU > performance test on QEMU or Fast Model naturally scales up on > real-hardware. Atleast we have never come across any scenario or test > performing better on QEMU or Fast Model compared real-world (this is true > for test running on Native Linux or Linux running as guest on Xvisor ARM). > > In our opinion we strongly believe monolithic approaches are always better > performing over micro-kernelized approaches (or approaches somewhere in > between micro-kernel and monolithic). Hence Xvisor ARM will always perform > better than KVM ARM in theory, simulation and real-world. > > Best Regards, > Anup Patel > > On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > >> On 6 May 2012 05:22, Anup Patel wrote: >> > Also can you give example of a code sequence which is faster on model >> and >> > slower in real world. As far as I know ARM fast models are internally >> TLM >> > based models and If a TLM based model is emulating a timer chip of X >> clock >> > then it is quite precise X clock. >> >> Support for TLM does not require that the underlying model is cycle >> accurate (you can have 'loosely timed' behaviour). >> >> You might want to read the Fast Models documentation, which tries >> to be clear about what the models do and don't provide. In particular: >> >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html >> "Fast models cannot be used to: >> * model cycle counting >> * model software performance >> " >> >> > Ofcourse CPU emulation and computation >> > power will be less compared to real world. To see this behaviour try to >> boot >> > linux on Fast model or QEMU and leave it for hours and come back see the >> > time elapsed, you will definitely see same amount of time elapsed as >> real >> > world. >> >> Nobody's arguing that the models are faster than hardware! >> Let's try a simple example with some numbers representing >> relative speeds: >> >> operation A: h/w: 1 ; model 5 >> operation B: h/w 3 ; model 30 >> >> Where we're comparing two equivalent code sequences "A A A A" vs "B". >> On hardware "B" will be faster. On the model the "A A A A" beats "B". >> (both sequences are slower on the model than on the hardware, obviously.) >> >> The point is that some operations will be vastly vastly slower >> on the model, and some operations merely moderately slower. Which >> of any two code sequences is fastest depends at least as much on >> whether it's using operations that are disproportionally worse >> on the model. A trivial example of this is VFP -- certainly QEMU >> has to do complex software emulation of the floating point ops to >> maintain bit-for-bit accuracy, which makes them very slow to the >> point where a hand-optimised-integer-assembly codec is likely to >> be faster on the model than a Neon/VFP-using codec, even though >> of course the Neon codec will be faster on hardware. >> >> [NB: this is itself a big simplification: model performance will >> depend on a lot of interacting things and is not purely a >> same-every-time slowdown per operation. Some operations effectively >> slow down what happens after them, for instance on QEMU if you do >> something that makes us flush our cache of translated code. And >> if for instance you have a periodic timer then the fact the model >> is generally slower means you execute proportionally more insns in >> the timer interrupt, so inefficiency or slowness in that code path >> has disproportionately more effect on overall speed than it does >> on hardware. There are other complications too...] >> >> > The results in the announcemnt are not baseless we have quite amount >> reasons >> > to believe Xvisor ARM will perform better than KVM ARM in real-world >> too. >> >> I'm not stating a position on whether KVM will be better or worse >> than Xvisor. I'm just pointing out that you can't base an argument >> on the faulty assumption that performance inside a model can tell >> you anything useful about performance on hardware. >> >> -- PMM >> > > _______________________________________________ > Android-virt mailing list > Android-virt@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > > --20cf3079b82652666904bf98898f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On May 9, 2012, at 2:11 AM, Anup Patel <anup@brainfault.org> wrote:

The intention behind the announcement = was to inform people interested in virtualization about Xvisor.

consider the members og this list informed.=A0
The announcement was an early info about= achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are= planning to have scientific paper for Xvisor.

Also, I do agree that KVM ARM can be further optimized but as I mention= ed in my previous replies "KVM ARM will end-up putting more and more s= tuff in-kernel". For now you can think of Xvisor ARM =3D KVM ARM doing= everything in-kernel. Even Xvisor ARM is being optimized so, as time passe= s Xvisor ARM is also going to improve further. Its a common wisdom that &qu= ot;No hypervisor in the world can be better than Native performance". = Xvisor ARM is already very very close to native performance and KVM ARM wil= l come close to native performance only by increasing its monolithic nature= (i.e. doing more things in-kernel). If monolithic hypervisors are so well = performing then why not to have a monolithic hypervisor made for virtualiza= tion purpose only. The motivation behind writing Xvisor was the same.

Apart from high performance Xvisor has many interesting features such a= s:
Ability to work without hardware virtualization support - Xvis= or ARM is able to boot multiple unmodified Linux guest even on hosts which = do not have virtualization extensions implemented. In contrast, KVM ARM doe= s not work without virtualization extension. The potential number of host h= ardware that Xvisor ARM can support is much more than KVM ARM can support. = Xvisor ARM can in-fact run on old ARMv5 processors too.
Tree-based configuration - To create a guest we have to just describ= e the guest in form of a device tree (possible even in runtime). In contras= t, for KVM one needs to add the support in QEMU and recompile the binaries.=
Pass-through hardware access - For hardware not accessed or virtuali= zed by Xvisor can be used in pass-through mode. Providing the guests a pass= -through accessible device is just matter of adding a tree node and configu= re irq routing information in guest tree. Its not just PCI devices, we can = provide any kind of device as pass-through accessible (Note: if device has = in-built DMA then it should have IOMMU or SysMMU otherwise it would be secu= rity breach). We have already tried out Serial Port and NIC as pass-through= devices.

We can compare KVM advantages with Xvisor as follows:
Scheduler - The linux kernel scheduler is very mature and proven OS scheduler but = Hypervisor scheduler can be quite different. Scheduling processes and sched= uling VMs can be very different problems. In case of VMs we can use info su= ch as: amount of emulated IO done, amount of time spend in waiting for irq,= etc for improving the quality of server consolidation.
Driver base - Xvisor has and will have all driver framework APIs sim= ilar to Linux and driver porting will be just one-on-one replacement of API= s in most cases.
User space tools - For starter Xvisor will use = libvirt tools (or similar open source initiative) for remote management. Co-existence host processes - Xvisor is not an OS. Its made for virt= ualization only so no process. Ofcourse, Xvisor has internal threading fram= ework but most of the time this background threads are sleeping doing nothi= ng. All the management commands are provided by=A0

--Anup

On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall <= cdall@cs.columbia.edu> wrote:

Anup,

Thanks for pro= viding info on your Xvisor project. However, this is a mailing list for the= development of KVM/ARM and not a scientific forum to establish in theory w= hich hypervisor "will always perform better than" which oth= er hypervisor.

If you want to establish that your c= ode base will always perform better than all other hosted hypervisors, I st= rongly encourage you to submit a paper about this in a peer reviewed confer= ence. Personally I would find that establishing such facts in a scientific = way to be extremely interesting.=A0

I understand that you w= ish to argue Xvisor's superiority in comparison to KVM, but I disagree = with your conclusions. The code path taken in KVM can be optimized to be ex= tremely short and all logic could be placed within the KVM module. There ar= e numerous other advantages to using KVM (existing driver base, upstream ke= rnel integration, compatibility with existing user space tools, co-existenc= e with native host processes, etc.) and with server grade hardware I see th= e reliance on the Linux kernel for scheduling, memory management etc. to be= a great advantage - and not a drawback. On the other hand, when Xvisor mat= ures, feature requests will only increase its code size and complexity as w= ell.

-Christoffer

On May 6, 2012, at 7:53 AM, Anup Patel <anup@brainfault.org> w= rote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup Patel <anup@brainfault.org> wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0 http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

_______= ________________________________________
Android-virt maili= ng list
Android-virt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/and= roid-virt

--20cf3079b82652666904bf98898f-- --===============8553920838609294694== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============8553920838609294694==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWy-0006j1-Cq; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQbsk-0003rC-Fy for xen-arm@lists.xensource.com; Sat, 05 May 2012 10:06:30 +0000 Received: from [193.109.254.147:34257] by server-8.bemta-14.messagelabs.com id A4/8A-23244-5ABF4AF4; Sat, 05 May 2012 10:06:29 +0000 X-Env-Sender: peter.maydell@linaro.org X-Msg-Ref: server-7.tower-27.messagelabs.com!1336212387!77010!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10010 invoked from network); 5 May 2012 10:06:29 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 10:06:29 -0000 Received: by obfk16 with SMTP id k16so7181115obf.30 for ; Sat, 05 May 2012 03:06:27 -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=sMZ4Wd0pTPl76B3K/zj9MZpmHlob7CHkply9MapD//A=; b=OZy1xPXaJGE0WEeD+Ft+3chGIdJ+KpK9iyGZWGbxWH8ob6Sd9WnXoPlO74MYmcng0W uIvvaJN9qmxUsiXV2qtHQMNBFJ/9mW+wQSH9V3+TeZTs8Zu5pu3swMKunxWeIq/m634A dormhX/zXn2laPTFiIAlDYZxktEYh/sGZlBY8zs7EQmHspvqZbBHMSmQlzjKWUY9l8Zn f7QSquzLEK/cl94MIQvXNGJqUrhl5RMyJ3yHuQo5znJY+AtUrYgYAZJibIzxD1VxCKVa bGuThFeXe5AFkwyByXRX0PVPSOqhkM2Vr2M8z5tIC3D1fR87p/T23jhIKYJK4auD+8W3 OzhQ== MIME-Version: 1.0 Received: by 10.50.188.138 with SMTP id ga10mr4779729igc.51.1336212387319; Sat, 05 May 2012 03:06:27 -0700 (PDT) Received: by 10.50.100.198 with HTTP; Sat, 5 May 2012 03:06:27 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 May 2012 11:06:27 +0100 Message-ID: From: Peter Maydell To: Anup Patel X-Gm-Message-State: ALoCoQl4N8O61MU4Oz1tHr8zwNsupCZRJUi3+4DcPy8ePEx+eInkNb4MK+lQF8FLqAkfhDC2MW5O X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: xen-arm@lists.xensource.com, Xvisor Devel , android-virt@lists.cs.columbia.edu, xen-arm@lists.xen.org Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org 2012/5/5 Anup Patel : > This announcement is to show an apple to apple performance comparison > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. I would strongly caution against trying to do any performance/timing type tests if you're still running on the ARM Fast Model -- they are not representative of performance characteristics on hardware and you really can't draw any conclusions about real world performance by timing things on a model. It's quite easy to get into a situation where all you're measuring is "does my code happen to do a lot of some perfectly reasonable operation which happens to be hard and slow to implement for the model?". (Also, KVM for ARM is still under development and we haven't yet made several of the obvious performance improvements like in-kernel irqchip and timer support, so it's not really a very useful thing to compare against yet.) -- PMM _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWz-0006k4-Bk; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRtNN-0003WL-Ef for xen-arm@lists.xensource.com; Tue, 08 May 2012 22:59:25 +0000 Received: from [85.158.143.99:41115] by server-1.bemta-4.messagelabs.com id D4/2E-20925-C45A9AF4; Tue, 08 May 2012 22:59:24 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-12.tower-216.messagelabs.com!1336517961!21823091!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15595 invoked from network); 8 May 2012 22:59:22 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 22:59:22 -0000 Received: by vbbfq11 with SMTP id fq11so2849919vbb.30 for ; Tue, 08 May 2012 15:59:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=2hrnN3xlahyNjwZHfBKaxq1ho6nKkmrWgX2el6KsidA=; b=KSTrj+Cpd/4x5pt2TNGfPXHx85bnVZcsHSM+Ii/gFlu5ug+AyRH9l7ELnSkbAwppQU 3CuTsZBI/iB9SmH1DsZClXyzKbIe9+A/+4oU+Sg5npW4WfbQhy+mJgC1XzztlaHXMDUv 43rkePFEUNZkapUiExJ8oZf4x6SWOdmo5zqFcQ9HvXdxA/imZ4jROJ4Jp/nWRAdiMgqM xI5FiepH8+k1v+k0Yfq2XDAtTPVEJRCJHKM7hyTz2Mv9avCETmEpxEZfmZaMAizxRTVP C/X1AcnD2OnoOgTUxijywtuWEFXz2zFaOB8oBGFZICQzow/jg9dde4tpZH/DYYPzRe7b I4LQ== Received: by 10.220.155.131 with SMTP id s3mr9405034vcw.15.1336517961316; Tue, 08 May 2012 15:59:21 -0700 (PDT) References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Tue, 8 May 2012 18:59:15 -0400 Message-ID: <-3890923700307571348@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQmuJ/JoHWfUTNBwUQ5CTFJCM7jEywTqZppx/E/FIXMfei18H1Ieo5Ss3FqfPC2D+MeLVMUL X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7267936705943970533==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============7267936705943970533== Content-Type: multipart/alternative; boundary=f46d04308a3a51fb7c04bf8e564f --f46d04308a3a51fb7c04bf8e564f Content-Type: text/plain; charset=ISO-8859-1 Anup, Thanks for providing info on your Xvisor project. However, this is a mailing list for the development of KVM/ARM and not a scientific forum to establish in theory which hypervisor "will always perform better than" which other hypervisor. If you want to establish that your code base will always perform better than all other hosted hypervisors, I strongly encourage you to submit a paper about this in a peer reviewed conference. Personally I would find that establishing such facts in a scientific way to be extremely interesting. I understand that you wish to argue Xvisor's superiority in comparison to KVM, but I disagree with your conclusions. The code path taken in KVM can be optimized to be extremely short and all logic could be placed within the KVM module. There are numerous other advantages to using KVM (existing driver base, upstream kernel integration, compatibility with existing user space tools, co-existence with native host processes, etc.) and with server grade hardware I see the reliance on the Linux kernel for scheduling, memory management etc. to be a great advantage - and not a drawback. On the other hand, when Xvisor matures, feature requests will only increase its code size and complexity as well. -Christoffer On May 6, 2012, at 7:53 AM, Anup Patel wrote: Hi PMM, Whether to consider model for measuring performance is one's own opinion. There are number of Tier1 conferences which accept simulation numbers for proving better approaches provided the simulation platform is well accepted by everyone. Talking about code sequences both Xvisor ARM and KVM ARM have same set of emulators and drivers. In fact, almost all emulation code has been adopted from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to guest mode and amount of code traversed in handling any fault is also very less hence Xvisor-ARM will have much less code executed compared to KVM ARM. In Xvisor developement, we have observed that results of any CPU performance test on QEMU or Fast Model naturally scales up on real-hardware. Atleast we have never come across any scenario or test performing better on QEMU or Fast Model compared real-world (this is true for test running on Native Linux or Linux running as guest on Xvisor ARM). In our opinion we strongly believe monolithic approaches are always better performing over micro-kernelized approaches (or approaches somewhere in between micro-kernel and monolithic). Hence Xvisor ARM will always perform better than KVM ARM in theory, simulation and real-world. Best Regards, Anup Patel On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > On 6 May 2012 05:22, Anup Patel wrote: > > Also can you give example of a code sequence which is faster on model and > > slower in real world. As far as I know ARM fast models are internally TLM > > based models and If a TLM based model is emulating a timer chip of X > clock > > then it is quite precise X clock. > > Support for TLM does not require that the underlying model is cycle > accurate (you can have 'loosely timed' behaviour). > > You might want to read the Fast Models documentation, which tries > to be clear about what the models do and don't provide. In particular: > http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html > "Fast models cannot be used to: > * model cycle counting > * model software performance > " > > > Ofcourse CPU emulation and computation > > power will be less compared to real world. To see this behaviour try to > boot > > linux on Fast model or QEMU and leave it for hours and come back see the > > time elapsed, you will definitely see same amount of time elapsed as real > > world. > > Nobody's arguing that the models are faster than hardware! > Let's try a simple example with some numbers representing > relative speeds: > > operation A: h/w: 1 ; model 5 > operation B: h/w 3 ; model 30 > > Where we're comparing two equivalent code sequences "A A A A" vs "B". > On hardware "B" will be faster. On the model the "A A A A" beats "B". > (both sequences are slower on the model than on the hardware, obviously.) > > The point is that some operations will be vastly vastly slower > on the model, and some operations merely moderately slower. Which > of any two code sequences is fastest depends at least as much on > whether it's using operations that are disproportionally worse > on the model. A trivial example of this is VFP -- certainly QEMU > has to do complex software emulation of the floating point ops to > maintain bit-for-bit accuracy, which makes them very slow to the > point where a hand-optimised-integer-assembly codec is likely to > be faster on the model than a Neon/VFP-using codec, even though > of course the Neon codec will be faster on hardware. > > [NB: this is itself a big simplification: model performance will > depend on a lot of interacting things and is not purely a > same-every-time slowdown per operation. Some operations effectively > slow down what happens after them, for instance on QEMU if you do > something that makes us flush our cache of translated code. And > if for instance you have a periodic timer then the fact the model > is generally slower means you execute proportionally more insns in > the timer interrupt, so inefficiency or slowness in that code path > has disproportionately more effect on overall speed than it does > on hardware. There are other complications too...] > > > The results in the announcemnt are not baseless we have quite amount > reasons > > to believe Xvisor ARM will perform better than KVM ARM in real-world too. > > I'm not stating a position on whether KVM will be better or worse > than Xvisor. I'm just pointing out that you can't base an argument > on the faulty assumption that performance inside a model can tell > you anything useful about performance on hardware. > > -- PMM > _______________________________________________ Android-virt mailing list Android-virt@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/android-virt --f46d04308a3a51fb7c04bf8e564f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Anup,

Thanks for providing info on your Xvisor project. However, this is a = mailing list for the development of KVM/ARM and not a scientific forum to e= stablish in theory which hypervisor "will always perform better than" which other hypervisor.<= /div>

If you want to establish that your code base = will always perform better than all other hosted hypervisors, I strongly en= courage you to submit a paper about this in a peer reviewed conference. Per= sonally I would find that establishing such facts in a scientific way to be= extremely interesting.=A0

<= div>I understand that you wish to ar= gue Xvisor's superiority in comparison to KVM, but I disagree with your= conclusions. The code path taken in KVM can be optimized to be extremely s= hort and all logic could be placed within the KVM module. There are numerou= s other advantages to using KVM (existing driver base, upstream kernel inte= gration, compatibility with existing user space tools, co-existence with na= tive host processes, etc.) and with server grade hardware I see the relianc= e on the Linux kernel for scheduling, memory management etc. to be a great = advantage - and not a drawback. On the other hand, when Xvisor matures, fea= ture requests will only increase its code size and complexity as well.

-Christoffer

On May 6, 2= 012, at 7:53 AM, Anup Patel <anup= @brainfault.org> wrote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup = Patel <anup@brainfault.org>= ; wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

___________________= ____________________________
Android-virt mailing list
Android-v= irt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/android-virt
--f46d04308a3a51fb7c04bf8e564f-- --===============7267936705943970533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============7267936705943970533==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWy-0006jD-IF; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQge7-0005cD-QX for xen-arm@lists.xensource.com; Sat, 05 May 2012 15:11:44 +0000 Received: from [85.158.139.83:9944] by server-8.bemta-5.messagelabs.com id 0C/95-26964-E2345AF4; Sat, 05 May 2012 15:11:42 +0000 X-Env-Sender: marc.zyngier@arm.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336230702!19559555!1 X-Originating-IP: [91.220.42.44] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDIxNzM4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19547 invoked from network); 5 May 2012 15:11:42 -0000 Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by server-16.tower-182.messagelabs.com with SMTP; 5 May 2012 15:11:42 -0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Sat, 05 May 2012 16:11:41 +0100 Received: from taxman.wild-wind.fr.eu.org ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 May 2012 16:13:12 +0100 Date: Sat, 5 May 2012 16:11:28 +0100 From: Marc Zyngier To: Anup Patel Message-ID: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> In-Reply-To: References: Organization: ARM Ltd X-Mailer: Claws Mail 3.8.0 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-OriginalArrivalTime: 05 May 2012 15:13:12.0659 (UTC) FILETIME=[96968230:01CD2AD1] X-MC-Unique: 112050516114100201 X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Sat, 5 May 2012 15:24:26 +0100 Anup Patel wrote: > Hi PMM, > > I agree we cannot predict real world performance based on performance on ARM fast models but if system A is performing better than system B no ARM fast model or QEMU then in real world system A will perform better than system B. Of-course in real world scale of difference in performance between system A and system B will differ. > You may want to re-read Peter's email, and consider that the model doesn't represent the micro-architecture. A code sequence X can be faster than a sequence Y on the model, and the opposite on real hardware. The same is equally valid on two different implementation of the same architecture (Cortex-A7 vs Cortex-A15, for example). > The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. On the Fast Model. M. > On Sat, May 5, 2012 at 3:36 PM, Peter Maydell > wrote: > 2012/5/5 Anup Patel >: > > This announcement is to show an apple to apple performance comparison > > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. > > I would strongly caution against trying to do any performance/timing > type tests if you're still running on the ARM Fast Model -- they are > not representative of performance characteristics on hardware > and you really can't draw any conclusions about real world > performance by timing things on a model. It's quite easy to get > into a situation where all you're measuring is "does my code happen > to do a lot of some perfectly reasonable operation which happens > to be hard and slow to implement for the model?". > > (Also, KVM for ARM is still under development and we haven't > yet made several of the obvious performance improvements like > in-kernel irqchip and timer support, so it's not really a very > useful thing to compare against yet.) > > -- PMM > -- I'm the slime oozin' out from your TV set... _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWz-0006k4-Bk; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRtNN-0003WL-Ef for xen-arm@lists.xensource.com; Tue, 08 May 2012 22:59:25 +0000 Received: from [85.158.143.99:41115] by server-1.bemta-4.messagelabs.com id D4/2E-20925-C45A9AF4; Tue, 08 May 2012 22:59:24 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-12.tower-216.messagelabs.com!1336517961!21823091!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15595 invoked from network); 8 May 2012 22:59:22 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 22:59:22 -0000 Received: by vbbfq11 with SMTP id fq11so2849919vbb.30 for ; Tue, 08 May 2012 15:59:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=2hrnN3xlahyNjwZHfBKaxq1ho6nKkmrWgX2el6KsidA=; b=KSTrj+Cpd/4x5pt2TNGfPXHx85bnVZcsHSM+Ii/gFlu5ug+AyRH9l7ELnSkbAwppQU 3CuTsZBI/iB9SmH1DsZClXyzKbIe9+A/+4oU+Sg5npW4WfbQhy+mJgC1XzztlaHXMDUv 43rkePFEUNZkapUiExJ8oZf4x6SWOdmo5zqFcQ9HvXdxA/imZ4jROJ4Jp/nWRAdiMgqM xI5FiepH8+k1v+k0Yfq2XDAtTPVEJRCJHKM7hyTz2Mv9avCETmEpxEZfmZaMAizxRTVP C/X1AcnD2OnoOgTUxijywtuWEFXz2zFaOB8oBGFZICQzow/jg9dde4tpZH/DYYPzRe7b I4LQ== Received: by 10.220.155.131 with SMTP id s3mr9405034vcw.15.1336517961316; Tue, 08 May 2012 15:59:21 -0700 (PDT) References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Tue, 8 May 2012 18:59:15 -0400 Message-ID: <-3890923700307571348@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQmuJ/JoHWfUTNBwUQ5CTFJCM7jEywTqZppx/E/FIXMfei18H1Ieo5Ss3FqfPC2D+MeLVMUL X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7267936705943970533==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============7267936705943970533== Content-Type: multipart/alternative; boundary=f46d04308a3a51fb7c04bf8e564f --f46d04308a3a51fb7c04bf8e564f Content-Type: text/plain; charset=ISO-8859-1 Anup, Thanks for providing info on your Xvisor project. However, this is a mailing list for the development of KVM/ARM and not a scientific forum to establish in theory which hypervisor "will always perform better than" which other hypervisor. If you want to establish that your code base will always perform better than all other hosted hypervisors, I strongly encourage you to submit a paper about this in a peer reviewed conference. Personally I would find that establishing such facts in a scientific way to be extremely interesting. I understand that you wish to argue Xvisor's superiority in comparison to KVM, but I disagree with your conclusions. The code path taken in KVM can be optimized to be extremely short and all logic could be placed within the KVM module. There are numerous other advantages to using KVM (existing driver base, upstream kernel integration, compatibility with existing user space tools, co-existence with native host processes, etc.) and with server grade hardware I see the reliance on the Linux kernel for scheduling, memory management etc. to be a great advantage - and not a drawback. On the other hand, when Xvisor matures, feature requests will only increase its code size and complexity as well. -Christoffer On May 6, 2012, at 7:53 AM, Anup Patel wrote: Hi PMM, Whether to consider model for measuring performance is one's own opinion. There are number of Tier1 conferences which accept simulation numbers for proving better approaches provided the simulation platform is well accepted by everyone. Talking about code sequences both Xvisor ARM and KVM ARM have same set of emulators and drivers. In fact, almost all emulation code has been adopted from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to guest mode and amount of code traversed in handling any fault is also very less hence Xvisor-ARM will have much less code executed compared to KVM ARM. In Xvisor developement, we have observed that results of any CPU performance test on QEMU or Fast Model naturally scales up on real-hardware. Atleast we have never come across any scenario or test performing better on QEMU or Fast Model compared real-world (this is true for test running on Native Linux or Linux running as guest on Xvisor ARM). In our opinion we strongly believe monolithic approaches are always better performing over micro-kernelized approaches (or approaches somewhere in between micro-kernel and monolithic). Hence Xvisor ARM will always perform better than KVM ARM in theory, simulation and real-world. Best Regards, Anup Patel On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > On 6 May 2012 05:22, Anup Patel wrote: > > Also can you give example of a code sequence which is faster on model and > > slower in real world. As far as I know ARM fast models are internally TLM > > based models and If a TLM based model is emulating a timer chip of X > clock > > then it is quite precise X clock. > > Support for TLM does not require that the underlying model is cycle > accurate (you can have 'loosely timed' behaviour). > > You might want to read the Fast Models documentation, which tries > to be clear about what the models do and don't provide. In particular: > http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html > "Fast models cannot be used to: > * model cycle counting > * model software performance > " > > > Ofcourse CPU emulation and computation > > power will be less compared to real world. To see this behaviour try to > boot > > linux on Fast model or QEMU and leave it for hours and come back see the > > time elapsed, you will definitely see same amount of time elapsed as real > > world. > > Nobody's arguing that the models are faster than hardware! > Let's try a simple example with some numbers representing > relative speeds: > > operation A: h/w: 1 ; model 5 > operation B: h/w 3 ; model 30 > > Where we're comparing two equivalent code sequences "A A A A" vs "B". > On hardware "B" will be faster. On the model the "A A A A" beats "B". > (both sequences are slower on the model than on the hardware, obviously.) > > The point is that some operations will be vastly vastly slower > on the model, and some operations merely moderately slower. Which > of any two code sequences is fastest depends at least as much on > whether it's using operations that are disproportionally worse > on the model. A trivial example of this is VFP -- certainly QEMU > has to do complex software emulation of the floating point ops to > maintain bit-for-bit accuracy, which makes them very slow to the > point where a hand-optimised-integer-assembly codec is likely to > be faster on the model than a Neon/VFP-using codec, even though > of course the Neon codec will be faster on hardware. > > [NB: this is itself a big simplification: model performance will > depend on a lot of interacting things and is not purely a > same-every-time slowdown per operation. Some operations effectively > slow down what happens after them, for instance on QEMU if you do > something that makes us flush our cache of translated code. And > if for instance you have a periodic timer then the fact the model > is generally slower means you execute proportionally more insns in > the timer interrupt, so inefficiency or slowness in that code path > has disproportionately more effect on overall speed than it does > on hardware. There are other complications too...] > > > The results in the announcemnt are not baseless we have quite amount > reasons > > to believe Xvisor ARM will perform better than KVM ARM in real-world too. > > I'm not stating a position on whether KVM will be better or worse > than Xvisor. I'm just pointing out that you can't base an argument > on the faulty assumption that performance inside a model can tell > you anything useful about performance on hardware. > > -- PMM > _______________________________________________ Android-virt mailing list Android-virt@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/android-virt --f46d04308a3a51fb7c04bf8e564f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Anup,

Thanks for providing info on your Xvisor project. However, this is a = mailing list for the development of KVM/ARM and not a scientific forum to e= stablish in theory which hypervisor "will always perform better than" which other hypervisor.<= /div>

If you want to establish that your code base = will always perform better than all other hosted hypervisors, I strongly en= courage you to submit a paper about this in a peer reviewed conference. Per= sonally I would find that establishing such facts in a scientific way to be= extremely interesting.=A0

<= div>I understand that you wish to ar= gue Xvisor's superiority in comparison to KVM, but I disagree with your= conclusions. The code path taken in KVM can be optimized to be extremely s= hort and all logic could be placed within the KVM module. There are numerou= s other advantages to using KVM (existing driver base, upstream kernel inte= gration, compatibility with existing user space tools, co-existence with na= tive host processes, etc.) and with server grade hardware I see the relianc= e on the Linux kernel for scheduling, memory management etc. to be a great = advantage - and not a drawback. On the other hand, when Xvisor matures, fea= ture requests will only increase its code size and complexity as well.

-Christoffer

On May 6, 2= 012, at 7:53 AM, Anup Patel <anup= @brainfault.org> wrote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup = Patel <anup@brainfault.org>= ; wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

___________________= ____________________________
Android-virt mailing list
Android-v= irt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/android-virt
--f46d04308a3a51fb7c04bf8e564f-- --===============7267936705943970533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============7267936705943970533==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWy-0006jZ-SX; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQuKR-0006GY-Q3 for xen-arm@lists.xensource.com; Sun, 06 May 2012 05:48:20 +0000 Received: from [85.158.139.83:36124] by server-11.bemta-5.messagelabs.com id 4C/5B-12959-2A016AF4; Sun, 06 May 2012 05:48:18 +0000 X-Env-Sender: hschauhan@nulltrace.org X-Msg-Ref: server-16.tower-182.messagelabs.com!1336283296!19609934!1 X-Originating-IP: [209.85.161.171] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1258 invoked from network); 6 May 2012 05:48:18 -0000 Received: from mail-gg0-f171.google.com (HELO mail-gg0-f171.google.com) (209.85.161.171) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 05:48:18 -0000 Received: by ggki1 with SMTP id i1so475984ggk.30 for ; Sat, 05 May 2012 22:48:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=uVY1tP0ul+KugJvNBoQGdLkFeSVFbOWTregpXiz0RVI=; b=HITltb3FFuGD6wsEHLlMQ6SnFpGhXNHAcdzTpeIG7g1uTSsvIioAQvkZzMuL7Lp3Zp 1pYx6Xqr2aTLEsB6qu7pbSdmSQboe6kf1oSZyAghyxeYmhESaNaNNnfuZUhrcBWEvUuf YuxMhfyynSpYNxoYkd1XGyksjbMvK9zQQcwqD+M3s0a/JMxgvciwvavPTuT5/dVnZD1/ v6Kmv2aRn2s80t7FXv0B8FUpprKBB75hULd4EmOBvqIgS6lcTw1y+UMinNJSo04bFkz/ QoJ2BJGv/0z4vEona+EJkeDivOrTkE+IqiGmOJSfrInVLr/thHydmtJXZMeBtNMUBvIm 7QLQ== Received: by 10.236.181.42 with SMTP id k30mr4571202yhm.42.1336283296333; Sat, 05 May 2012 22:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.123.6 with HTTP; Sat, 5 May 2012 22:47:35 -0700 (PDT) X-Originating-IP: [122.167.110.121] In-Reply-To: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> References: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> From: "Chauhan, Himanshu" Date: Sun, 6 May 2012 11:17:35 +0530 Message-ID: To: xvisor-devel@googlegroups.com X-Gm-Message-State: ALoCoQk1biWM3ZLxDI2lRXCiiuk0i9mpvp/tYxz9WwrhyCUc5k+xVH28D2H/pUvAAU6Zix5ZlNIw X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: "xen-arm@lists.xen.org" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" , Peter Maydell Subject: Re: [XenARM] [xvisor-devel] Re: [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0531262949691829400==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============0531262949691829400== Content-Type: multipart/alternative; boundary=20cf305b0f9a32802204bf57b3d3 --20cf305b0f9a32802204bf57b3d3 Content-Type: text/plain; charset=ISO-8859-1 > The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. > > On the Fast Model. > > To quote from ARM site: "the Fast Models can help developers debug, analyze, and __optimize__ their applications throughout the development cycle." If fast models are not as is (which I understand they don't represent the microarchitecture), why care about optimizations in fast model then? I believe if X-Visor wins on fast model on what ever reasons, it WILL win on hardware as well. We must accept this. = Himanshu = --20cf305b0f9a32802204bf57b3d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > The previous announcement only proves that Xvisor ARM is relatively be= tter than KVM ARM.

On the Fast Model.

To quote from ARM site:

"the Fast Models= can help developers debug, analyze, and __optimize__ their applications th= roughout the development cycle."

If fast models are not as is (= which I understand they don't represent the microarchitecture), why car= e about optimizations in fast model then?

I believe if X-Visor wins on fast model on what ever reasons, it WILL w= in on hardware as well. We must accept this.

=3D Himanshu =3D

--20cf305b0f9a32802204bf57b3d3-- --===============0531262949691829400== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============0531262949691829400==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWz-0006kf-N1; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4te-00026b-Pf for xen-arm@lists.xensource.com; Wed, 09 May 2012 11:17:31 +0000 Received: from [85.158.139.83:48774] by server-10.bemta-5.messagelabs.com id 90/5F-08260-A425AAF4; Wed, 09 May 2012 11:17:30 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-2.tower-182.messagelabs.com!1336562246!27442990!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5456 invoked from network); 9 May 2012 11:17:27 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:17:27 -0000 Received: by vbbfq11 with SMTP id fq11so216455vbb.30 for ; Wed, 09 May 2012 04:17:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ksy4Sm2M9P9+h47SjYcgosjhXKAm3/qobf9aXA0Irsw=; b=POvkS74jwAEFSDFVGdjpz949c5CAr7D98SeAJfyYjvLq7SIOdMM345kBY/xukdF3y2 lAIpv5SmTF3d8cZNztHchgTXSaCNPQL20Q4vbXoyWmnB4CqedGkKpW6CBmOsscwefOb7 zBiaei7DF/SikNuXHaR+0sWryJ2/CaIexhHt4STM5jZiBWjtk1LljPeSYmzOyQVpPPNR c0SdzYnT47SFgauRmwO0Q6zVbZc/RruvoqvfIkY06WxhzFCTelpOcLfIauarPCWbcHbQ 01wROxn3QqnLGAxouz67JDqvDzSfgPBPkzDldLzy9SYwynn45sELUJ9EdS27YgiMYOcV Sqmw== Received: by 10.220.155.131 with SMTP id s3mr10605715vcw.15.1336562215355; Wed, 09 May 2012 04:16:55 -0700 (PDT) References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> <-3890923700307571348@unknownmsgid> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Wed, 9 May 2012 07:16:45 -0400 Message-ID: <-6403728154748147809@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQkZ9D4YpAYkvIPBtDqrMDbETDyzFHdf1++ggYrodxAaDcWY6N5+KL0SV8mEwQCr7LwMwyEg X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Christoffer Dall , Peter Maydell , "xen-arm@lists.xensource.com" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" , Xvisor Devel Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5093224415487449303==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============5093224415487449303== Content-Type: multipart/alternative; boundary=f46d04308a3a11046b04bf98a481 --f46d04308a3a11046b04bf98a481 Content-Type: text/plain; charset=ISO-8859-1 On May 9, 2012, at 2:11 AM, Anup Patel wrote: The intention behind the announcement was to inform people interested in virtualization about Xvisor. The announcement was an early info about achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planning to have scientific paper for Xvisor. consider the members of this list informed Also, I do agree that KVM ARM can be further optimized but as I mentioned in my previous replies "KVM ARM will end-up putting more and more stuff in-kernel". For now you can think of Xvisor ARM = KVM ARM doing everything in-kernel. Even Xvisor ARM is being optimized so, as time passes Xvisor ARM is also going to improve further. Its a common wisdom that "No hypervisor in the world can be better than Native performance". Xvisor ARM is already very very close to native performance and KVM ARM will come close to native performance only by increasing its monolithic nature (i.e. doing more things in-kernel). If monolithic hypervisors are so well performing then why not to have a monolithic hypervisor made for virtualization purpose only. The motivation behind writing Xvisor was the same. Apart from high performance Xvisor has many interesting features such as: *Ability to work without hardware virtualization support* - Xvisor ARM is able to boot multiple unmodified Linux guest even on hosts which do not have virtualization extensions implemented. In contrast, KVM ARM does not work without virtualization extension. The potential number of host hardware that Xvisor ARM can support is much more than KVM ARM can support. Xvisor ARM can in-fact run on old ARMv5 processors too. *Tree-based configuration* - To create a guest we have to just describe the guest in form of a device tree (possible even in runtime). In contrast, for KVM one needs to add the support in QEMU and recompile the binaries. *Pass-through hardware access* - For hardware not accessed or virtualized by Xvisor can be used in pass-through mode. Providing the guests a pass-through accessible device is just matter of adding a tree node and configure irq routing information in guest tree. Its not just PCI devices, we can provide any kind of device as pass-through accessible (Note: if device has in-built DMA then it should have IOMMU or SysMMU otherwise it would be security breach). We have already tried out Serial Port and NIC as pass-through devices. We can compare KVM advantages with Xvisor as follows: *Scheduler* - The linux kernel scheduler is very mature and proven OS scheduler but Hypervisor scheduler can be quite different. Scheduling processes and scheduling VMs can be very different problems. In case of VMs we can use info such as: amount of emulated IO done, amount of time spend in waiting for irq, etc for improving the quality of server consolidation. *Driver base* - Xvisor has and will have all driver framework APIs similar to Linux and driver porting will be just one-on-one replacement of APIs in most cases. *User space tools* - For starter Xvisor will use libvirt tools (or similar open source initiative) for remote management. *Co-existence host processes* - Xvisor is not an OS. Its made for virtualization only so no process. Ofcourse, Xvisor has internal threading framework but most of the time this background threads are sleeping doing nothing. All the management commands are provided by managment terminal daemon (which a background thread in Xvisor). This all sounds fantastic! But as I said, this list is for the development of KVM/ARM and not a place for arguing how fantastic Xvisor is as opposed to everything else. Please keep that in mind. I am looking forward to your paper. On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall wrote: > Anup, > > Thanks for providing info on your Xvisor project. However, this is a > mailing list for the development of KVM/ARM and not a scientific forum to > establish in theory which hypervisor "will always perform better than" > which other hypervisor. > > If you want to establish that your code base will always perform better > than all other hosted hypervisors, I strongly encourage you to submit a > paper about this in a peer reviewed conference. Personally I would find > that establishing such facts in a scientific way to be extremely > interesting. > > I understand that you wish to argue Xvisor's superiority in comparison to > KVM, but I disagree with your conclusions. The code path taken in KVM can > be optimized to be extremely short and all logic could be placed within the > KVM module. There are numerous other advantages to using KVM (existing > driver base, upstream kernel integration, compatibility with existing user > space tools, co-existence with native host processes, etc.) and with server > grade hardware I see the reliance on the Linux kernel for scheduling, > memory management etc. to be a great advantage - and not a drawback. On the > other hand, when Xvisor matures, feature requests will only increase its > code size and complexity as well. > > -Christoffer > > On May 6, 2012, at 7:53 AM, Anup Patel wrote: > > Hi PMM, > > Whether to consider model for measuring performance is one's own opinion. > There are number of Tier1 conferences which accept simulation numbers for > proving better approaches provided the simulation platform is well accepted > by everyone. > > Talking about code sequences both Xvisor ARM and KVM ARM have same set of > emulators and drivers. In fact, almost all emulation code has been adopted > from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike > KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to > guest mode and amount of code traversed in handling any fault is also very > less hence Xvisor-ARM will have much less code executed compared to KVM ARM. > > In Xvisor developement, we have observed that results of any CPU > performance test on QEMU or Fast Model naturally scales up on > real-hardware. Atleast we have never come across any scenario or test > performing better on QEMU or Fast Model compared real-world (this is true > for test running on Native Linux or Linux running as guest on Xvisor ARM). > > In our opinion we strongly believe monolithic approaches are always better > performing over micro-kernelized approaches (or approaches somewhere in > between micro-kernel and monolithic). Hence Xvisor ARM will always perform > better than KVM ARM in theory, simulation and real-world. > > Best Regards, > Anup Patel > > On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > >> On 6 May 2012 05:22, Anup Patel wrote: >> > Also can you give example of a code sequence which is faster on model >> and >> > slower in real world. As far as I know ARM fast models are internally >> TLM >> > based models and If a TLM based model is emulating a timer chip of X >> clock >> > then it is quite precise X clock. >> >> Support for TLM does not require that the underlying model is cycle >> accurate (you can have 'loosely timed' behaviour). >> >> You might want to read the Fast Models documentation, which tries >> to be clear about what the models do and don't provide. In particular: >> >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html >> "Fast models cannot be used to: >> * model cycle counting >> * model software performance >> " >> >> > Ofcourse CPU emulation and computation >> > power will be less compared to real world. To see this behaviour try to >> boot >> > linux on Fast model or QEMU and leave it for hours and come back see the >> > time elapsed, you will definitely see same amount of time elapsed as >> real >> > world. >> >> Nobody's arguing that the models are faster than hardware! >> Let's try a simple example with some numbers representing >> relative speeds: >> >> operation A: h/w: 1 ; model 5 >> operation B: h/w 3 ; model 30 >> >> Where we're comparing two equivalent code sequences "A A A A" vs "B". >> On hardware "B" will be faster. On the model the "A A A A" beats "B". >> (both sequences are slower on the model than on the hardware, obviously.) >> >> The point is that some operations will be vastly vastly slower >> on the model, and some operations merely moderately slower. Which >> of any two code sequences is fastest depends at least as much on >> whether it's using operations that are disproportionally worse >> on the model. A trivial example of this is VFP -- certainly QEMU >> has to do complex software emulation of the floating point ops to >> maintain bit-for-bit accuracy, which makes them very slow to the >> point where a hand-optimised-integer-assembly codec is likely to >> be faster on the model than a Neon/VFP-using codec, even though >> of course the Neon codec will be faster on hardware. >> >> [NB: this is itself a big simplification: model performance will >> depend on a lot of interacting things and is not purely a >> same-every-time slowdown per operation. Some operations effectively >> slow down what happens after them, for instance on QEMU if you do >> something that makes us flush our cache of translated code. And >> if for instance you have a periodic timer then the fact the model >> is generally slower means you execute proportionally more insns in >> the timer interrupt, so inefficiency or slowness in that code path >> has disproportionately more effect on overall speed than it does >> on hardware. There are other complications too...] >> >> > The results in the announcemnt are not baseless we have quite amount >> reasons >> > to believe Xvisor ARM will perform better than KVM ARM in real-world >> too. >> >> I'm not stating a position on whether KVM will be better or worse >> than Xvisor. I'm just pointing out that you can't base an argument >> on the faulty assumption that performance inside a model can tell >> you anything useful about performance on hardware. >> >> -- PMM >> > > _______________________________________________ > Android-virt mailing list > Android-virt@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > > --f46d04308a3a11046b04bf98a481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On May 9, = 2012, at 2:11 AM, Anup Patel <anu= p@brainfault.org> wrote:

The intention behind the announcement was to inform people interested in v= irtualization about Xvisor. The announcement was an early info about achiev= ements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planni= ng to have scientific paper for Xvisor.

consider the members of this list informed
Also, I do agree that KVM ARM can be fu= rther optimized but as I mentioned in my previous replies "KVM ARM wil= l end-up putting more and more stuff in-kernel". For now you can think= of Xvisor ARM =3D KVM ARM doing everything in-kernel. Even Xvisor ARM is b= eing optimized so, as time passes Xvisor ARM is also going to improve furth= er. Its a common wisdom that "No hypervisor in the world can be better= than Native performance". Xvisor ARM is already very very close to na= tive performance and KVM ARM will come close to native performance only by = increasing its monolithic nature (i.e. doing more things in-kernel). If mon= olithic hypervisors are so well performing then why not to have a monolithi= c hypervisor made for virtualization purpose only. The motivation behind wr= iting Xvisor was the same.

Apart from high performance Xvisor has many interesting features such a= s:
Ability to work without hardware virtualization support - Xvis= or ARM is able to boot multiple unmodified Linux guest even on hosts which = do not have virtualization extensions implemented. In contrast, KVM ARM doe= s not work without virtualization extension. The potential number of host h= ardware that Xvisor ARM can support is much more than KVM ARM can support. = Xvisor ARM can in-fact run on old ARMv5 processors too.
Tree-based configuration - To create a guest we have to just describ= e the guest in form of a device tree (possible even in runtime). In contras= t, for KVM one needs to add the support in QEMU and recompile the binaries.=
Pass-through hardware access - For hardware not accessed or virtuali= zed by Xvisor can be used in pass-through mode. Providing the guests a pass= -through accessible device is just matter of adding a tree node and configu= re irq routing information in guest tree. Its not just PCI devices, we can = provide any kind of device as pass-through accessible (Note: if device has = in-built DMA then it should have IOMMU or SysMMU otherwise it would be secu= rity breach). We have already tried out Serial Port and NIC as pass-through= devices.

We can compare KVM advantages with Xvisor as follows:
Scheduler - The linux kernel scheduler is very mature and proven OS scheduler but = Hypervisor scheduler can be quite different. Scheduling processes and sched= uling VMs can be very different problems. In case of VMs we can use info su= ch as: amount of emulated IO done, amount of time spend in waiting for irq,= etc for improving the quality of server consolidation.
Driver base - Xvisor has and will have all driver framework APIs sim= ilar to Linux and driver porting will be just one-on-one replacement of API= s in most cases.
User space tools - For starter Xvisor will use = libvirt tools (or similar open source initiative) for remote management. Co-existence host processes - Xvisor is not an OS. Its made for virt= ualization only so no process. Ofcourse, Xvisor has internal threading fram= ework but most of the time this background threads are sleeping doing nothi= ng. All the management commands are provided by managment terminal daemon (= which a background thread in Xvisor).

This all sounds fantastic!

But as I said, this list is for the development of KVM/ARM = and not a place for arguing how fantastic Xvisor is as opposed to everythin= g else. Please keep that in mind.=A0

I am looking forward to your paper.=A0

On Wed, May 9, 2012 = at 4:29 AM, Christoffer Dall <cdall@cs.columbia.edu> wro= te:

Anup,

Thanks for pro= viding info on your Xvisor project. However, this is a mailing list for the= development of KVM/ARM and not a scientific forum to establish in theory w= hich hypervisor "will always perform better than" which oth= er hypervisor.

If you want to establish that your c= ode base will always perform better than all other hosted hypervisors, I st= rongly encourage you to submit a paper about this in a peer reviewed confer= ence. Personally I would find that establishing such facts in a scientific = way to be extremely interesting.=A0

I understand that you w= ish to argue Xvisor's superiority in comparison to KVM, but I disagree = with your conclusions. The code path taken in KVM can be optimized to be ex= tremely short and all logic could be placed within the KVM module. There ar= e numerous other advantages to using KVM (existing driver base, upstream ke= rnel integration, compatibility with existing user space tools, co-existenc= e with native host processes, etc.) and with server grade hardware I see th= e reliance on the Linux kernel for scheduling, memory management etc. to be= a great advantage - and not a drawback. On the other hand, when Xvisor mat= ures, feature requests will only increase its code size and complexity as w= ell.

-Christoffer

On May 6, 2012, at 7:53 AM, Anup Patel <anup@brainfault.org> w= rote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup Patel <anup@brainfault.org> wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0 http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

_______= ________________________________________
Android-virt maili= ng list
Android-virt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/and= roid-virt

--f46d04308a3a11046b04bf98a481-- --===============5093224415487449303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============5093224415487449303==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqX0-0006lN-1i; Tue, 22 May 2012 14:57:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVM2Z-0006OB-Ha for xen-arm@lists.xensource.com; Fri, 18 May 2012 12:12:15 +0000 Received: from [85.158.143.35:47889] by server-2.bemta-4.messagelabs.com id 70/D9-12211-E9C36BF4; Fri, 18 May 2012 12:12:14 +0000 X-Env-Sender: seehwan.yoo@gmail.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1337343121!16044325!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_23,ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDcwNTY3MDkgKHRpbWVvdXQp\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21248 invoked from network); 18 May 2012 12:12:03 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 12:12:03 -0000 Received: by pbcwz7 with SMTP id wz7so4325961pbc.30 for ; Fri, 18 May 2012 05:12:01 -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=s42J3x+jpKmOvnPAh59hXq/Z6PkyKhZTLxTLQp/yiDU=; b=TjxhUIqIopdB3KeENstkHeM5oYtPpdfYTrbggnva8YDyKboxhpQw/kce7UpQLD/3US hCfhpFfCqMsmHlBrNq/rZ5wwU8NcaWSYd63/f2e24hBHO+dPcEDQeYak6v4N7ChDy0PV +MDf9A6l0LLTCXKaXM2uU6WwOtHqdMZMckuEcGfWeSqXTP0z9aiH8lOmdhQzqg3mqCD3 ypvhTbbgbLck76SaO6Thepp3yTF36a8egbIxmKoxkU4VlQZp9gzz7HZ94ca7T734TCxB 4+vojj3d2dlOtZJKaDooEWAWRJo4FQ7vxG1Xm4QukAo1phSqdtkMZT1vWuSPxQdiHeV2 k4Qg== Received: by 10.68.189.198 with SMTP id gk6mr38185876pbc.31.1337343112204; Fri, 18 May 2012 05:11:52 -0700 (PDT) Received: from [192.168.0.13] ([163.152.162.99]) by mx.google.com with ESMTPS id pj5sm12621235pbb.51.2012.05.18.05.11.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 May 2012 05:11:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) From: Seehwan Yoo In-Reply-To: Date: Fri, 18 May 2012 21:11:47 +0900 Message-Id: <56C765CA-598E-465B-AC3A-7BC594CEEC2B@gmail.com> References: To: Krishna Pavan X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Xen Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0811596592471585464==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============0811596592471585464== Content-Type: multipart/alternative; boundary="Apple-Mail=_814A236D-CD32-4620-ADA5-730CB7285408" --Apple-Mail=_814A236D-CD32-4620-ADA5-730CB7285408 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi,=20 We've been working with Xen-ARM_pv for cortex-a8. We've run two guest Linux.=20 Our H/W platform is with s5pc100 that uses cortex-a8 core. Seehwan Yoo=20 Ph. D. candidate T + 82-2-3290-3639 F + 82-2-922-6341 E shyoo@os.korea.ac.kr =09 Home Page | Blog | OSVirtual =09 OSLab. =E2=80=A2 Korea Univ. =E2=80=A2 Seoul =E2=80=A2 South = Korea 2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E=91=EC=84=B1: > Hi, >=20 > Please inform the status of Xen-ARM for Cortex-A8 CPU's on FME from = ARM. >=20 > These links here=20 > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions=20 > &=20 > = http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastMode= ls >=20 > give information about the dom0 running on FME. >=20 > Though Xen-ARM is available for Cortex-A9 with KVM Virt extensions for = Tegra2Harmony, >=20 > Cortex-A8 is widely used, and I would like to know the status. >=20 > So, Kindly inform, so that, we could learn more about/from it. > --=20 > =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D >=20 > _______________________________________________ > Xen-arm mailing list > Xen-arm@lists.xen.org > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --Apple-Mail=_814A236D-CD32-4620-ADA5-730CB7285408 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Untitled Document =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
=20 Seehwan Yoo
=20 =20   Ph. D. candidate

=20 =20 T + = 82-2-3290-3639
=20 =20 F + = 82-2-922-6341
=20 =20 E shyoo@os.korea.ac.kr
=20
=20 Home Page | =20 Blog | =20 OSVirtual=20
OSLab. =E2=80=A2=20= Korea Univ. =E2=80=A2=20 Seoul  =E2=80=A2=20 South Korea=20

2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan = =EC=9E=91=EC=84=B1:

Hi,

Please inform the status = of Xen-ARM for Cortex-A8 CPU's on FME from ARM.

These links here =
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions
&
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensi= ons/FastModels

give information about = the dom0 running on FME.

Though Xen-ARM is = available for Cortex-A9 with KVM Virt extensions for = Tegra2Harmony,

Cortex-A8 is widely = used, and I would like to know the status.

So, Kindly inform, so = that, we could learn more about/from it.
--
=E2=9C=89= Regards :: Krishna = Pavan =E2=9C=8D

_______________________________________________
Xen-arm mailing = list
Xen-arm@lists.xen.org
http://= lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

<= /div>= --Apple-Mail=_814A236D-CD32-4620-ADA5-730CB7285408-- --===============0811596592471585464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============0811596592471585464==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWz-0006kO-FY; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4lu-0001pD-MK for xen-arm@lists.xen.org; Wed, 09 May 2012 11:09:31 +0000 Received: from [193.109.254.147:40235] by server-7.bemta-14.messagelabs.com id 19/DA-01627-9605AAF4; Wed, 09 May 2012 11:09:29 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-10.tower-27.messagelabs.com!1336561767!3210553!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18194 invoked from network); 9 May 2012 11:09:28 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:09:28 -0000 Received: by vbbfn1 with SMTP id fn1so223916vbb.32 for ; Wed, 09 May 2012 04:09:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Iip9unawQeOcSC76fLUnbwyIhGYIcbxrJEMwS+RW1uM=; b=DKCJe8ChAPBhxF4cNHllgrWYMTHMjPJtj7939Pzt0Z07VWPE+aKCHRXqtN/DJy5DDa DXmaGKPvSpC7sb93d4ob64xDcMngd9gTD6Uus8fKd/otymHdnBmKWE+y1pfOJk6FdEgE m1V2KCFudRQEY2+SuGd8fWwHYc5V88VOzd9aIJvbH17VJmqUnZdeCHlU98sVZ6sQTKR/ Fa5YuISHZ5JTws1S1KPRDILbek55DNPsmX+JOcoUdgN6G/22PN6BgXeInV2jNr0yC9GE 97tYgzbY/aoe0mUDNOfZu1ZjJubJkZC0wLCwJOCqXdWfClIh/jD/yQitq3ecjp9bvWhV FsWw== Received: by 10.52.34.79 with SMTP id x15mr10532740vdi.0.1336561766655; Wed, 09 May 2012 04:09:26 -0700 (PDT) References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> <-3890923700307571348@unknownmsgid> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Wed, 9 May 2012 07:09:22 -0400 Message-ID: <5386794781075909369@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQkHtiK4qioPec+n+s8UgBrE5/KLKncc2LYDOyHJDVHLz9FPsoaVM3N3SNeRs/nNYqk6AeP5 X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Christoffer Dall , Peter Maydell , "xen-arm@lists.xensource.com" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" , Xvisor Devel Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7027563077152306247==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============7027563077152306247== Content-Type: multipart/alternative; boundary=20cf3079b82652666904bf98898f --20cf3079b82652666904bf98898f Content-Type: text/plain; charset=ISO-8859-1 On May 9, 2012, at 2:11 AM, Anup Patel wrote: The intention behind the announcement was to inform people interested in virtualization about Xvisor. consider the members og this list informed. The announcement was an early info about achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planning to have scientific paper for Xvisor. Also, I do agree that KVM ARM can be further optimized but as I mentioned in my previous replies "KVM ARM will end-up putting more and more stuff in-kernel". For now you can think of Xvisor ARM = KVM ARM doing everything in-kernel. Even Xvisor ARM is being optimized so, as time passes Xvisor ARM is also going to improve further. Its a common wisdom that "No hypervisor in the world can be better than Native performance". Xvisor ARM is already very very close to native performance and KVM ARM will come close to native performance only by increasing its monolithic nature (i.e. doing more things in-kernel). If monolithic hypervisors are so well performing then why not to have a monolithic hypervisor made for virtualization purpose only. The motivation behind writing Xvisor was the same. Apart from high performance Xvisor has many interesting features such as: *Ability to work without hardware virtualization support* - Xvisor ARM is able to boot multiple unmodified Linux guest even on hosts which do not have virtualization extensions implemented. In contrast, KVM ARM does not work without virtualization extension. The potential number of host hardware that Xvisor ARM can support is much more than KVM ARM can support. Xvisor ARM can in-fact run on old ARMv5 processors too. *Tree-based configuration* - To create a guest we have to just describe the guest in form of a device tree (possible even in runtime). In contrast, for KVM one needs to add the support in QEMU and recompile the binaries. *Pass-through hardware access* - For hardware not accessed or virtualized by Xvisor can be used in pass-through mode. Providing the guests a pass-through accessible device is just matter of adding a tree node and configure irq routing information in guest tree. Its not just PCI devices, we can provide any kind of device as pass-through accessible (Note: if device has in-built DMA then it should have IOMMU or SysMMU otherwise it would be security breach). We have already tried out Serial Port and NIC as pass-through devices. We can compare KVM advantages with Xvisor as follows: *Scheduler* - The linux kernel scheduler is very mature and proven OS scheduler but Hypervisor scheduler can be quite different. Scheduling processes and scheduling VMs can be very different problems. In case of VMs we can use info such as: amount of emulated IO done, amount of time spend in waiting for irq, etc for improving the quality of server consolidation. *Driver base* - Xvisor has and will have all driver framework APIs similar to Linux and driver porting will be just one-on-one replacement of APIs in most cases. *User space tools* - For starter Xvisor will use libvirt tools (or similar open source initiative) for remote management. *Co-existence host processes* - Xvisor is not an OS. Its made for virtualization only so no process. Ofcourse, Xvisor has internal threading framework but most of the time this background threads are sleeping doing nothing. All the management commands are provided by --Anup On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall wrote: > Anup, > > Thanks for providing info on your Xvisor project. However, this is a > mailing list for the development of KVM/ARM and not a scientific forum to > establish in theory which hypervisor "will always perform better than" > which other hypervisor. > > If you want to establish that your code base will always perform better > than all other hosted hypervisors, I strongly encourage you to submit a > paper about this in a peer reviewed conference. Personally I would find > that establishing such facts in a scientific way to be extremely > interesting. > > I understand that you wish to argue Xvisor's superiority in comparison to > KVM, but I disagree with your conclusions. The code path taken in KVM can > be optimized to be extremely short and all logic could be placed within the > KVM module. There are numerous other advantages to using KVM (existing > driver base, upstream kernel integration, compatibility with existing user > space tools, co-existence with native host processes, etc.) and with server > grade hardware I see the reliance on the Linux kernel for scheduling, > memory management etc. to be a great advantage - and not a drawback. On the > other hand, when Xvisor matures, feature requests will only increase its > code size and complexity as well. > > -Christoffer > > On May 6, 2012, at 7:53 AM, Anup Patel wrote: > > Hi PMM, > > Whether to consider model for measuring performance is one's own opinion. > There are number of Tier1 conferences which accept simulation numbers for > proving better approaches provided the simulation platform is well accepted > by everyone. > > Talking about code sequences both Xvisor ARM and KVM ARM have same set of > emulators and drivers. In fact, almost all emulation code has been adopted > from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike > KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to > guest mode and amount of code traversed in handling any fault is also very > less hence Xvisor-ARM will have much less code executed compared to KVM ARM. > > In Xvisor developement, we have observed that results of any CPU > performance test on QEMU or Fast Model naturally scales up on > real-hardware. Atleast we have never come across any scenario or test > performing better on QEMU or Fast Model compared real-world (this is true > for test running on Native Linux or Linux running as guest on Xvisor ARM). > > In our opinion we strongly believe monolithic approaches are always better > performing over micro-kernelized approaches (or approaches somewhere in > between micro-kernel and monolithic). Hence Xvisor ARM will always perform > better than KVM ARM in theory, simulation and real-world. > > Best Regards, > Anup Patel > > On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > >> On 6 May 2012 05:22, Anup Patel wrote: >> > Also can you give example of a code sequence which is faster on model >> and >> > slower in real world. As far as I know ARM fast models are internally >> TLM >> > based models and If a TLM based model is emulating a timer chip of X >> clock >> > then it is quite precise X clock. >> >> Support for TLM does not require that the underlying model is cycle >> accurate (you can have 'loosely timed' behaviour). >> >> You might want to read the Fast Models documentation, which tries >> to be clear about what the models do and don't provide. In particular: >> >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html >> "Fast models cannot be used to: >> * model cycle counting >> * model software performance >> " >> >> > Ofcourse CPU emulation and computation >> > power will be less compared to real world. To see this behaviour try to >> boot >> > linux on Fast model or QEMU and leave it for hours and come back see the >> > time elapsed, you will definitely see same amount of time elapsed as >> real >> > world. >> >> Nobody's arguing that the models are faster than hardware! >> Let's try a simple example with some numbers representing >> relative speeds: >> >> operation A: h/w: 1 ; model 5 >> operation B: h/w 3 ; model 30 >> >> Where we're comparing two equivalent code sequences "A A A A" vs "B". >> On hardware "B" will be faster. On the model the "A A A A" beats "B". >> (both sequences are slower on the model than on the hardware, obviously.) >> >> The point is that some operations will be vastly vastly slower >> on the model, and some operations merely moderately slower. Which >> of any two code sequences is fastest depends at least as much on >> whether it's using operations that are disproportionally worse >> on the model. A trivial example of this is VFP -- certainly QEMU >> has to do complex software emulation of the floating point ops to >> maintain bit-for-bit accuracy, which makes them very slow to the >> point where a hand-optimised-integer-assembly codec is likely to >> be faster on the model than a Neon/VFP-using codec, even though >> of course the Neon codec will be faster on hardware. >> >> [NB: this is itself a big simplification: model performance will >> depend on a lot of interacting things and is not purely a >> same-every-time slowdown per operation. Some operations effectively >> slow down what happens after them, for instance on QEMU if you do >> something that makes us flush our cache of translated code. And >> if for instance you have a periodic timer then the fact the model >> is generally slower means you execute proportionally more insns in >> the timer interrupt, so inefficiency or slowness in that code path >> has disproportionately more effect on overall speed than it does >> on hardware. There are other complications too...] >> >> > The results in the announcemnt are not baseless we have quite amount >> reasons >> > to believe Xvisor ARM will perform better than KVM ARM in real-world >> too. >> >> I'm not stating a position on whether KVM will be better or worse >> than Xvisor. I'm just pointing out that you can't base an argument >> on the faulty assumption that performance inside a model can tell >> you anything useful about performance on hardware. >> >> -- PMM >> > > _______________________________________________ > Android-virt mailing list > Android-virt@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > > --20cf3079b82652666904bf98898f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On May 9, 2012, at 2:11 AM, Anup Patel <anup@brainfault.org> wrote:

The intention behind the announcement = was to inform people interested in virtualization about Xvisor.

consider the members og this list informed.=A0
The announcement was an early info about= achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are= planning to have scientific paper for Xvisor.

Also, I do agree that KVM ARM can be further optimized but as I mention= ed in my previous replies "KVM ARM will end-up putting more and more s= tuff in-kernel". For now you can think of Xvisor ARM =3D KVM ARM doing= everything in-kernel. Even Xvisor ARM is being optimized so, as time passe= s Xvisor ARM is also going to improve further. Its a common wisdom that &qu= ot;No hypervisor in the world can be better than Native performance". = Xvisor ARM is already very very close to native performance and KVM ARM wil= l come close to native performance only by increasing its monolithic nature= (i.e. doing more things in-kernel). If monolithic hypervisors are so well = performing then why not to have a monolithic hypervisor made for virtualiza= tion purpose only. The motivation behind writing Xvisor was the same.

Apart from high performance Xvisor has many interesting features such a= s:
Ability to work without hardware virtualization support - Xvis= or ARM is able to boot multiple unmodified Linux guest even on hosts which = do not have virtualization extensions implemented. In contrast, KVM ARM doe= s not work without virtualization extension. The potential number of host h= ardware that Xvisor ARM can support is much more than KVM ARM can support. = Xvisor ARM can in-fact run on old ARMv5 processors too.
Tree-based configuration - To create a guest we have to just describ= e the guest in form of a device tree (possible even in runtime). In contras= t, for KVM one needs to add the support in QEMU and recompile the binaries.=
Pass-through hardware access - For hardware not accessed or virtuali= zed by Xvisor can be used in pass-through mode. Providing the guests a pass= -through accessible device is just matter of adding a tree node and configu= re irq routing information in guest tree. Its not just PCI devices, we can = provide any kind of device as pass-through accessible (Note: if device has = in-built DMA then it should have IOMMU or SysMMU otherwise it would be secu= rity breach). We have already tried out Serial Port and NIC as pass-through= devices.

We can compare KVM advantages with Xvisor as follows:
Scheduler - The linux kernel scheduler is very mature and proven OS scheduler but = Hypervisor scheduler can be quite different. Scheduling processes and sched= uling VMs can be very different problems. In case of VMs we can use info su= ch as: amount of emulated IO done, amount of time spend in waiting for irq,= etc for improving the quality of server consolidation.
Driver base - Xvisor has and will have all driver framework APIs sim= ilar to Linux and driver porting will be just one-on-one replacement of API= s in most cases.
User space tools - For starter Xvisor will use = libvirt tools (or similar open source initiative) for remote management. Co-existence host processes - Xvisor is not an OS. Its made for virt= ualization only so no process. Ofcourse, Xvisor has internal threading fram= ework but most of the time this background threads are sleeping doing nothi= ng. All the management commands are provided by=A0

--Anup

On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall <= cdall@cs.columbia.edu> wrote:

Anup,

Thanks for pro= viding info on your Xvisor project. However, this is a mailing list for the= development of KVM/ARM and not a scientific forum to establish in theory w= hich hypervisor "will always perform better than" which oth= er hypervisor.

If you want to establish that your c= ode base will always perform better than all other hosted hypervisors, I st= rongly encourage you to submit a paper about this in a peer reviewed confer= ence. Personally I would find that establishing such facts in a scientific = way to be extremely interesting.=A0

I understand that you w= ish to argue Xvisor's superiority in comparison to KVM, but I disagree = with your conclusions. The code path taken in KVM can be optimized to be ex= tremely short and all logic could be placed within the KVM module. There ar= e numerous other advantages to using KVM (existing driver base, upstream ke= rnel integration, compatibility with existing user space tools, co-existenc= e with native host processes, etc.) and with server grade hardware I see th= e reliance on the Linux kernel for scheduling, memory management etc. to be= a great advantage - and not a drawback. On the other hand, when Xvisor mat= ures, feature requests will only increase its code size and complexity as w= ell.

-Christoffer

On May 6, 2012, at 7:53 AM, Anup Patel <anup@brainfault.org> w= rote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup Patel <anup@brainfault.org> wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0 http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

_______= ________________________________________
Android-virt maili= ng list
Android-virt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/and= roid-virt

--20cf3079b82652666904bf98898f-- --===============7027563077152306247== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============7027563077152306247==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWy-0006jD-IF; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQge7-0005cD-QX for xen-arm@lists.xensource.com; Sat, 05 May 2012 15:11:44 +0000 Received: from [85.158.139.83:9944] by server-8.bemta-5.messagelabs.com id 0C/95-26964-E2345AF4; Sat, 05 May 2012 15:11:42 +0000 X-Env-Sender: marc.zyngier@arm.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336230702!19559555!1 X-Originating-IP: [91.220.42.44] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDIxNzM4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19547 invoked from network); 5 May 2012 15:11:42 -0000 Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by server-16.tower-182.messagelabs.com with SMTP; 5 May 2012 15:11:42 -0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Sat, 05 May 2012 16:11:41 +0100 Received: from taxman.wild-wind.fr.eu.org ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 May 2012 16:13:12 +0100 Date: Sat, 5 May 2012 16:11:28 +0100 From: Marc Zyngier To: Anup Patel Message-ID: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> In-Reply-To: References: Organization: ARM Ltd X-Mailer: Claws Mail 3.8.0 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-OriginalArrivalTime: 05 May 2012 15:13:12.0659 (UTC) FILETIME=[96968230:01CD2AD1] X-MC-Unique: 112050516114100201 X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Peter Maydell , "xen-arm@lists.xen.org" , Xvisor Devel , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Sat, 5 May 2012 15:24:26 +0100 Anup Patel wrote: > Hi PMM, > > I agree we cannot predict real world performance based on performance on ARM fast models but if system A is performing better than system B no ARM fast model or QEMU then in real world system A will perform better than system B. Of-course in real world scale of difference in performance between system A and system B will differ. > You may want to re-read Peter's email, and consider that the model doesn't represent the micro-architecture. A code sequence X can be faster than a sequence Y on the model, and the opposite on real hardware. The same is equally valid on two different implementation of the same architecture (Cortex-A7 vs Cortex-A15, for example). > The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. On the Fast Model. M. > On Sat, May 5, 2012 at 3:36 PM, Peter Maydell > wrote: > 2012/5/5 Anup Patel >: > > This announcement is to show an apple to apple performance comparison > > between Xvisor ARM and KVM ARM running on VExpress-A15 Fast Model. > > I would strongly caution against trying to do any performance/timing > type tests if you're still running on the ARM Fast Model -- they are > not representative of performance characteristics on hardware > and you really can't draw any conclusions about real world > performance by timing things on a model. It's quite easy to get > into a situation where all you're measuring is "does my code happen > to do a lot of some perfectly reasonable operation which happens > to be hard and slow to implement for the model?". > > (Also, KVM for ARM is still under development and we haven't > yet made several of the obvious performance improvements like > in-kernel irqchip and timer support, so it's not really a very > useful thing to compare against yet.) > > -- PMM > -- I'm the slime oozin' out from your TV set... _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqX0-0006lN-1i; Tue, 22 May 2012 14:57:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SVM2Z-0006OB-Ha for xen-arm@lists.xensource.com; Fri, 18 May 2012 12:12:15 +0000 Received: from [85.158.143.35:47889] by server-2.bemta-4.messagelabs.com id 70/D9-12211-E9C36BF4; Fri, 18 May 2012 12:12:14 +0000 X-Env-Sender: seehwan.yoo@gmail.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1337343121!16044325!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_23,ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDcwNTY3MDkgKHRpbWVvdXQp\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21248 invoked from network); 18 May 2012 12:12:03 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 18 May 2012 12:12:03 -0000 Received: by pbcwz7 with SMTP id wz7so4325961pbc.30 for ; Fri, 18 May 2012 05:12:01 -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=s42J3x+jpKmOvnPAh59hXq/Z6PkyKhZTLxTLQp/yiDU=; b=TjxhUIqIopdB3KeENstkHeM5oYtPpdfYTrbggnva8YDyKboxhpQw/kce7UpQLD/3US hCfhpFfCqMsmHlBrNq/rZ5wwU8NcaWSYd63/f2e24hBHO+dPcEDQeYak6v4N7ChDy0PV +MDf9A6l0LLTCXKaXM2uU6WwOtHqdMZMckuEcGfWeSqXTP0z9aiH8lOmdhQzqg3mqCD3 ypvhTbbgbLck76SaO6Thepp3yTF36a8egbIxmKoxkU4VlQZp9gzz7HZ94ca7T734TCxB 4+vojj3d2dlOtZJKaDooEWAWRJo4FQ7vxG1Xm4QukAo1phSqdtkMZT1vWuSPxQdiHeV2 k4Qg== Received: by 10.68.189.198 with SMTP id gk6mr38185876pbc.31.1337343112204; Fri, 18 May 2012 05:11:52 -0700 (PDT) Received: from [192.168.0.13] ([163.152.162.99]) by mx.google.com with ESMTPS id pj5sm12621235pbb.51.2012.05.18.05.11.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 May 2012 05:11:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) From: Seehwan Yoo In-Reply-To: Date: Fri, 18 May 2012 21:11:47 +0900 Message-Id: <56C765CA-598E-465B-AC3A-7BC594CEEC2B@gmail.com> References: To: Krishna Pavan X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Xen Subject: Re: [XenARM] Regarding Xen-ARM for Cortex-A8 on Fast Model Emulators [FME] X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0811596592471585464==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============0811596592471585464== Content-Type: multipart/alternative; boundary="Apple-Mail=_814A236D-CD32-4620-ADA5-730CB7285408" --Apple-Mail=_814A236D-CD32-4620-ADA5-730CB7285408 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi,=20 We've been working with Xen-ARM_pv for cortex-a8. We've run two guest Linux.=20 Our H/W platform is with s5pc100 that uses cortex-a8 core. Seehwan Yoo=20 Ph. D. candidate T + 82-2-3290-3639 F + 82-2-922-6341 E shyoo@os.korea.ac.kr =09 Home Page | Blog | OSVirtual =09 OSLab. =E2=80=A2 Korea Univ. =E2=80=A2 Seoul =E2=80=A2 South = Korea 2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan =EC=9E=91=EC=84=B1: > Hi, >=20 > Please inform the status of Xen-ARM for Cortex-A8 CPU's on FME from = ARM. >=20 > These links here=20 > http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions=20 > &=20 > = http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastMode= ls >=20 > give information about the dom0 running on FME. >=20 > Though Xen-ARM is available for Cortex-A9 with KVM Virt extensions for = Tegra2Harmony, >=20 > Cortex-A8 is widely used, and I would like to know the status. >=20 > So, Kindly inform, so that, we could learn more about/from it. > --=20 > =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D >=20 > _______________________________________________ > Xen-arm mailing list > Xen-arm@lists.xen.org > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --Apple-Mail=_814A236D-CD32-4620-ADA5-730CB7285408 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Untitled Document =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
=20 Seehwan Yoo
=20 =20   Ph. D. candidate

=20 =20 T + = 82-2-3290-3639
=20 =20 F + = 82-2-922-6341
=20 =20 E shyoo@os.korea.ac.kr
=20
=20 Home Page | =20 Blog | =20 OSVirtual=20
OSLab. =E2=80=A2=20= Korea Univ. =E2=80=A2=20 Seoul  =E2=80=A2=20 South Korea=20

2012. 5. 18., =EC=98=A4=ED=9B=84 8:38, Krishna Pavan = =EC=9E=91=EC=84=B1:

Hi,

Please inform the status = of Xen-ARM for Cortex-A8 CPU's on FME from ARM.

These links here =
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions
&
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensi= ons/FastModels

give information about = the dom0 running on FME.

Though Xen-ARM is = available for Cortex-A9 with KVM Virt extensions for = Tegra2Harmony,

Cortex-A8 is widely = used, and I would like to know the status.

So, Kindly inform, so = that, we could learn more about/from it.
--
=E2=9C=89= Regards :: Krishna = Pavan =E2=9C=8D

_______________________________________________
Xen-arm mailing = list
Xen-arm@lists.xen.org
http://= lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

<= /div>= --Apple-Mail=_814A236D-CD32-4620-ADA5-730CB7285408-- --===============0811596592471585464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============0811596592471585464==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWy-0006jZ-SX; Tue, 22 May 2012 14:57:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQuKR-0006GY-Q3 for xen-arm@lists.xensource.com; Sun, 06 May 2012 05:48:20 +0000 Received: from [85.158.139.83:36124] by server-11.bemta-5.messagelabs.com id 4C/5B-12959-2A016AF4; Sun, 06 May 2012 05:48:18 +0000 X-Env-Sender: hschauhan@nulltrace.org X-Msg-Ref: server-16.tower-182.messagelabs.com!1336283296!19609934!1 X-Originating-IP: [209.85.161.171] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1258 invoked from network); 6 May 2012 05:48:18 -0000 Received: from mail-gg0-f171.google.com (HELO mail-gg0-f171.google.com) (209.85.161.171) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 05:48:18 -0000 Received: by ggki1 with SMTP id i1so475984ggk.30 for ; Sat, 05 May 2012 22:48:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=uVY1tP0ul+KugJvNBoQGdLkFeSVFbOWTregpXiz0RVI=; b=HITltb3FFuGD6wsEHLlMQ6SnFpGhXNHAcdzTpeIG7g1uTSsvIioAQvkZzMuL7Lp3Zp 1pYx6Xqr2aTLEsB6qu7pbSdmSQboe6kf1oSZyAghyxeYmhESaNaNNnfuZUhrcBWEvUuf YuxMhfyynSpYNxoYkd1XGyksjbMvK9zQQcwqD+M3s0a/JMxgvciwvavPTuT5/dVnZD1/ v6Kmv2aRn2s80t7FXv0B8FUpprKBB75hULd4EmOBvqIgS6lcTw1y+UMinNJSo04bFkz/ QoJ2BJGv/0z4vEona+EJkeDivOrTkE+IqiGmOJSfrInVLr/thHydmtJXZMeBtNMUBvIm 7QLQ== Received: by 10.236.181.42 with SMTP id k30mr4571202yhm.42.1336283296333; Sat, 05 May 2012 22:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.123.6 with HTTP; Sat, 5 May 2012 22:47:35 -0700 (PDT) X-Originating-IP: [122.167.110.121] In-Reply-To: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> References: <20120505161128.3e538686@taxman.wild-wind.fr.eu.org> From: "Chauhan, Himanshu" Date: Sun, 6 May 2012 11:17:35 +0530 Message-ID: To: xvisor-devel@googlegroups.com X-Gm-Message-State: ALoCoQk1biWM3ZLxDI2lRXCiiuk0i9mpvp/tYxz9WwrhyCUc5k+xVH28D2H/pUvAAU6Zix5ZlNIw X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: "xen-arm@lists.xen.org" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xensource.com" , Peter Maydell Subject: Re: [XenARM] [xvisor-devel] Re: [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0531262949691829400==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============0531262949691829400== Content-Type: multipart/alternative; boundary=20cf305b0f9a32802204bf57b3d3 --20cf305b0f9a32802204bf57b3d3 Content-Type: text/plain; charset=ISO-8859-1 > The previous announcement only proves that Xvisor ARM is relatively better than KVM ARM. > > On the Fast Model. > > To quote from ARM site: "the Fast Models can help developers debug, analyze, and __optimize__ their applications throughout the development cycle." If fast models are not as is (which I understand they don't represent the microarchitecture), why care about optimizations in fast model then? I believe if X-Visor wins on fast model on what ever reasons, it WILL win on hardware as well. We must accept this. = Himanshu = --20cf305b0f9a32802204bf57b3d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > The previous announcement only proves that Xvisor ARM is relatively be= tter than KVM ARM.

On the Fast Model.

To quote from ARM site:

"the Fast Models= can help developers debug, analyze, and __optimize__ their applications th= roughout the development cycle."

If fast models are not as is (= which I understand they don't represent the microarchitecture), why car= e about optimizations in fast model then?

I believe if X-Visor wins on fast model on what ever reasons, it WILL w= in on hardware as well. We must accept this.

=3D Himanshu =3D

--20cf305b0f9a32802204bf57b3d3-- --===============0531262949691829400== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============0531262949691829400==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWz-0006kf-N1; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4te-00026b-Pf for xen-arm@lists.xensource.com; Wed, 09 May 2012 11:17:31 +0000 Received: from [85.158.139.83:48774] by server-10.bemta-5.messagelabs.com id 90/5F-08260-A425AAF4; Wed, 09 May 2012 11:17:30 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-2.tower-182.messagelabs.com!1336562246!27442990!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5456 invoked from network); 9 May 2012 11:17:27 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:17:27 -0000 Received: by vbbfq11 with SMTP id fq11so216455vbb.30 for ; Wed, 09 May 2012 04:17:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ksy4Sm2M9P9+h47SjYcgosjhXKAm3/qobf9aXA0Irsw=; b=POvkS74jwAEFSDFVGdjpz949c5CAr7D98SeAJfyYjvLq7SIOdMM345kBY/xukdF3y2 lAIpv5SmTF3d8cZNztHchgTXSaCNPQL20Q4vbXoyWmnB4CqedGkKpW6CBmOsscwefOb7 zBiaei7DF/SikNuXHaR+0sWryJ2/CaIexhHt4STM5jZiBWjtk1LljPeSYmzOyQVpPPNR c0SdzYnT47SFgauRmwO0Q6zVbZc/RruvoqvfIkY06WxhzFCTelpOcLfIauarPCWbcHbQ 01wROxn3QqnLGAxouz67JDqvDzSfgPBPkzDldLzy9SYwynn45sELUJ9EdS27YgiMYOcV Sqmw== Received: by 10.220.155.131 with SMTP id s3mr10605715vcw.15.1336562215355; Wed, 09 May 2012 04:16:55 -0700 (PDT) References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> <-3890923700307571348@unknownmsgid> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Wed, 9 May 2012 07:16:45 -0400 Message-ID: <-6403728154748147809@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQkZ9D4YpAYkvIPBtDqrMDbETDyzFHdf1++ggYrodxAaDcWY6N5+KL0SV8mEwQCr7LwMwyEg X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Christoffer Dall , Peter Maydell , "xen-arm@lists.xensource.com" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" , Xvisor Devel Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5093224415487449303==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============5093224415487449303== Content-Type: multipart/alternative; boundary=f46d04308a3a11046b04bf98a481 --f46d04308a3a11046b04bf98a481 Content-Type: text/plain; charset=ISO-8859-1 On May 9, 2012, at 2:11 AM, Anup Patel wrote: The intention behind the announcement was to inform people interested in virtualization about Xvisor. The announcement was an early info about achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planning to have scientific paper for Xvisor. consider the members of this list informed Also, I do agree that KVM ARM can be further optimized but as I mentioned in my previous replies "KVM ARM will end-up putting more and more stuff in-kernel". For now you can think of Xvisor ARM = KVM ARM doing everything in-kernel. Even Xvisor ARM is being optimized so, as time passes Xvisor ARM is also going to improve further. Its a common wisdom that "No hypervisor in the world can be better than Native performance". Xvisor ARM is already very very close to native performance and KVM ARM will come close to native performance only by increasing its monolithic nature (i.e. doing more things in-kernel). If monolithic hypervisors are so well performing then why not to have a monolithic hypervisor made for virtualization purpose only. The motivation behind writing Xvisor was the same. Apart from high performance Xvisor has many interesting features such as: *Ability to work without hardware virtualization support* - Xvisor ARM is able to boot multiple unmodified Linux guest even on hosts which do not have virtualization extensions implemented. In contrast, KVM ARM does not work without virtualization extension. The potential number of host hardware that Xvisor ARM can support is much more than KVM ARM can support. Xvisor ARM can in-fact run on old ARMv5 processors too. *Tree-based configuration* - To create a guest we have to just describe the guest in form of a device tree (possible even in runtime). In contrast, for KVM one needs to add the support in QEMU and recompile the binaries. *Pass-through hardware access* - For hardware not accessed or virtualized by Xvisor can be used in pass-through mode. Providing the guests a pass-through accessible device is just matter of adding a tree node and configure irq routing information in guest tree. Its not just PCI devices, we can provide any kind of device as pass-through accessible (Note: if device has in-built DMA then it should have IOMMU or SysMMU otherwise it would be security breach). We have already tried out Serial Port and NIC as pass-through devices. We can compare KVM advantages with Xvisor as follows: *Scheduler* - The linux kernel scheduler is very mature and proven OS scheduler but Hypervisor scheduler can be quite different. Scheduling processes and scheduling VMs can be very different problems. In case of VMs we can use info such as: amount of emulated IO done, amount of time spend in waiting for irq, etc for improving the quality of server consolidation. *Driver base* - Xvisor has and will have all driver framework APIs similar to Linux and driver porting will be just one-on-one replacement of APIs in most cases. *User space tools* - For starter Xvisor will use libvirt tools (or similar open source initiative) for remote management. *Co-existence host processes* - Xvisor is not an OS. Its made for virtualization only so no process. Ofcourse, Xvisor has internal threading framework but most of the time this background threads are sleeping doing nothing. All the management commands are provided by managment terminal daemon (which a background thread in Xvisor). This all sounds fantastic! But as I said, this list is for the development of KVM/ARM and not a place for arguing how fantastic Xvisor is as opposed to everything else. Please keep that in mind. I am looking forward to your paper. On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall wrote: > Anup, > > Thanks for providing info on your Xvisor project. However, this is a > mailing list for the development of KVM/ARM and not a scientific forum to > establish in theory which hypervisor "will always perform better than" > which other hypervisor. > > If you want to establish that your code base will always perform better > than all other hosted hypervisors, I strongly encourage you to submit a > paper about this in a peer reviewed conference. Personally I would find > that establishing such facts in a scientific way to be extremely > interesting. > > I understand that you wish to argue Xvisor's superiority in comparison to > KVM, but I disagree with your conclusions. The code path taken in KVM can > be optimized to be extremely short and all logic could be placed within the > KVM module. There are numerous other advantages to using KVM (existing > driver base, upstream kernel integration, compatibility with existing user > space tools, co-existence with native host processes, etc.) and with server > grade hardware I see the reliance on the Linux kernel for scheduling, > memory management etc. to be a great advantage - and not a drawback. On the > other hand, when Xvisor matures, feature requests will only increase its > code size and complexity as well. > > -Christoffer > > On May 6, 2012, at 7:53 AM, Anup Patel wrote: > > Hi PMM, > > Whether to consider model for measuring performance is one's own opinion. > There are number of Tier1 conferences which accept simulation numbers for > proving better approaches provided the simulation platform is well accepted > by everyone. > > Talking about code sequences both Xvisor ARM and KVM ARM have same set of > emulators and drivers. In fact, almost all emulation code has been adopted > from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike > KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to > guest mode and amount of code traversed in handling any fault is also very > less hence Xvisor-ARM will have much less code executed compared to KVM ARM. > > In Xvisor developement, we have observed that results of any CPU > performance test on QEMU or Fast Model naturally scales up on > real-hardware. Atleast we have never come across any scenario or test > performing better on QEMU or Fast Model compared real-world (this is true > for test running on Native Linux or Linux running as guest on Xvisor ARM). > > In our opinion we strongly believe monolithic approaches are always better > performing over micro-kernelized approaches (or approaches somewhere in > between micro-kernel and monolithic). Hence Xvisor ARM will always perform > better than KVM ARM in theory, simulation and real-world. > > Best Regards, > Anup Patel > > On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > >> On 6 May 2012 05:22, Anup Patel wrote: >> > Also can you give example of a code sequence which is faster on model >> and >> > slower in real world. As far as I know ARM fast models are internally >> TLM >> > based models and If a TLM based model is emulating a timer chip of X >> clock >> > then it is quite precise X clock. >> >> Support for TLM does not require that the underlying model is cycle >> accurate (you can have 'loosely timed' behaviour). >> >> You might want to read the Fast Models documentation, which tries >> to be clear about what the models do and don't provide. In particular: >> >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html >> "Fast models cannot be used to: >> * model cycle counting >> * model software performance >> " >> >> > Ofcourse CPU emulation and computation >> > power will be less compared to real world. To see this behaviour try to >> boot >> > linux on Fast model or QEMU and leave it for hours and come back see the >> > time elapsed, you will definitely see same amount of time elapsed as >> real >> > world. >> >> Nobody's arguing that the models are faster than hardware! >> Let's try a simple example with some numbers representing >> relative speeds: >> >> operation A: h/w: 1 ; model 5 >> operation B: h/w 3 ; model 30 >> >> Where we're comparing two equivalent code sequences "A A A A" vs "B". >> On hardware "B" will be faster. On the model the "A A A A" beats "B". >> (both sequences are slower on the model than on the hardware, obviously.) >> >> The point is that some operations will be vastly vastly slower >> on the model, and some operations merely moderately slower. Which >> of any two code sequences is fastest depends at least as much on >> whether it's using operations that are disproportionally worse >> on the model. A trivial example of this is VFP -- certainly QEMU >> has to do complex software emulation of the floating point ops to >> maintain bit-for-bit accuracy, which makes them very slow to the >> point where a hand-optimised-integer-assembly codec is likely to >> be faster on the model than a Neon/VFP-using codec, even though >> of course the Neon codec will be faster on hardware. >> >> [NB: this is itself a big simplification: model performance will >> depend on a lot of interacting things and is not purely a >> same-every-time slowdown per operation. Some operations effectively >> slow down what happens after them, for instance on QEMU if you do >> something that makes us flush our cache of translated code. And >> if for instance you have a periodic timer then the fact the model >> is generally slower means you execute proportionally more insns in >> the timer interrupt, so inefficiency or slowness in that code path >> has disproportionately more effect on overall speed than it does >> on hardware. There are other complications too...] >> >> > The results in the announcemnt are not baseless we have quite amount >> reasons >> > to believe Xvisor ARM will perform better than KVM ARM in real-world >> too. >> >> I'm not stating a position on whether KVM will be better or worse >> than Xvisor. I'm just pointing out that you can't base an argument >> on the faulty assumption that performance inside a model can tell >> you anything useful about performance on hardware. >> >> -- PMM >> > > _______________________________________________ > Android-virt mailing list > Android-virt@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > > --f46d04308a3a11046b04bf98a481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On May 9, = 2012, at 2:11 AM, Anup Patel <anu= p@brainfault.org> wrote:

The intention behind the announcement was to inform people interested in v= irtualization about Xvisor. The announcement was an early info about achiev= ements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planni= ng to have scientific paper for Xvisor.

consider the members of this list informed
Also, I do agree that KVM ARM can be fu= rther optimized but as I mentioned in my previous replies "KVM ARM wil= l end-up putting more and more stuff in-kernel". For now you can think= of Xvisor ARM =3D KVM ARM doing everything in-kernel. Even Xvisor ARM is b= eing optimized so, as time passes Xvisor ARM is also going to improve furth= er. Its a common wisdom that "No hypervisor in the world can be better= than Native performance". Xvisor ARM is already very very close to na= tive performance and KVM ARM will come close to native performance only by = increasing its monolithic nature (i.e. doing more things in-kernel). If mon= olithic hypervisors are so well performing then why not to have a monolithi= c hypervisor made for virtualization purpose only. The motivation behind wr= iting Xvisor was the same.

Apart from high performance Xvisor has many interesting features such a= s:
Ability to work without hardware virtualization support - Xvis= or ARM is able to boot multiple unmodified Linux guest even on hosts which = do not have virtualization extensions implemented. In contrast, KVM ARM doe= s not work without virtualization extension. The potential number of host h= ardware that Xvisor ARM can support is much more than KVM ARM can support. = Xvisor ARM can in-fact run on old ARMv5 processors too.
Tree-based configuration - To create a guest we have to just describ= e the guest in form of a device tree (possible even in runtime). In contras= t, for KVM one needs to add the support in QEMU and recompile the binaries.=
Pass-through hardware access - For hardware not accessed or virtuali= zed by Xvisor can be used in pass-through mode. Providing the guests a pass= -through accessible device is just matter of adding a tree node and configu= re irq routing information in guest tree. Its not just PCI devices, we can = provide any kind of device as pass-through accessible (Note: if device has = in-built DMA then it should have IOMMU or SysMMU otherwise it would be secu= rity breach). We have already tried out Serial Port and NIC as pass-through= devices.

We can compare KVM advantages with Xvisor as follows:
Scheduler - The linux kernel scheduler is very mature and proven OS scheduler but = Hypervisor scheduler can be quite different. Scheduling processes and sched= uling VMs can be very different problems. In case of VMs we can use info su= ch as: amount of emulated IO done, amount of time spend in waiting for irq,= etc for improving the quality of server consolidation.
Driver base - Xvisor has and will have all driver framework APIs sim= ilar to Linux and driver porting will be just one-on-one replacement of API= s in most cases.
User space tools - For starter Xvisor will use = libvirt tools (or similar open source initiative) for remote management. Co-existence host processes - Xvisor is not an OS. Its made for virt= ualization only so no process. Ofcourse, Xvisor has internal threading fram= ework but most of the time this background threads are sleeping doing nothi= ng. All the management commands are provided by managment terminal daemon (= which a background thread in Xvisor).

This all sounds fantastic!

But as I said, this list is for the development of KVM/ARM = and not a place for arguing how fantastic Xvisor is as opposed to everythin= g else. Please keep that in mind.=A0

I am looking forward to your paper.=A0

On Wed, May 9, 2012 = at 4:29 AM, Christoffer Dall <cdall@cs.columbia.edu> wro= te:

Anup,

Thanks for pro= viding info on your Xvisor project. However, this is a mailing list for the= development of KVM/ARM and not a scientific forum to establish in theory w= hich hypervisor "will always perform better than" which oth= er hypervisor.

If you want to establish that your c= ode base will always perform better than all other hosted hypervisors, I st= rongly encourage you to submit a paper about this in a peer reviewed confer= ence. Personally I would find that establishing such facts in a scientific = way to be extremely interesting.=A0

I understand that you w= ish to argue Xvisor's superiority in comparison to KVM, but I disagree = with your conclusions. The code path taken in KVM can be optimized to be ex= tremely short and all logic could be placed within the KVM module. There ar= e numerous other advantages to using KVM (existing driver base, upstream ke= rnel integration, compatibility with existing user space tools, co-existenc= e with native host processes, etc.) and with server grade hardware I see th= e reliance on the Linux kernel for scheduling, memory management etc. to be= a great advantage - and not a drawback. On the other hand, when Xvisor mat= ures, feature requests will only increase its code size and complexity as w= ell.

-Christoffer

On May 6, 2012, at 7:53 AM, Anup Patel <anup@brainfault.org> w= rote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup Patel <anup@brainfault.org> wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0 http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

_______= ________________________________________
Android-virt maili= ng list
Android-virt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/and= roid-virt

--f46d04308a3a11046b04bf98a481-- --===============5093224415487449303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============5093224415487449303==-- From xen-arm-bounces@lists.xen.org Tue May 22 14:57:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 14: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 1SWqWz-0006kO-FY; Tue, 22 May 2012 14:57:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4lu-0001pD-MK for xen-arm@lists.xen.org; Wed, 09 May 2012 11:09:31 +0000 Received: from [193.109.254.147:40235] by server-7.bemta-14.messagelabs.com id 19/DA-01627-9605AAF4; Wed, 09 May 2012 11:09:29 +0000 X-Env-Sender: christofferdall@christofferdall.dk X-Msg-Ref: server-10.tower-27.messagelabs.com!1336561767!3210553!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18194 invoked from network); 9 May 2012 11:09:28 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:09:28 -0000 Received: by vbbfn1 with SMTP id fn1so223916vbb.32 for ; Wed, 09 May 2012 04:09:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Iip9unawQeOcSC76fLUnbwyIhGYIcbxrJEMwS+RW1uM=; b=DKCJe8ChAPBhxF4cNHllgrWYMTHMjPJtj7939Pzt0Z07VWPE+aKCHRXqtN/DJy5DDa DXmaGKPvSpC7sb93d4ob64xDcMngd9gTD6Uus8fKd/otymHdnBmKWE+y1pfOJk6FdEgE m1V2KCFudRQEY2+SuGd8fWwHYc5V88VOzd9aIJvbH17VJmqUnZdeCHlU98sVZ6sQTKR/ Fa5YuISHZ5JTws1S1KPRDILbek55DNPsmX+JOcoUdgN6G/22PN6BgXeInV2jNr0yC9GE 97tYgzbY/aoe0mUDNOfZu1ZjJubJkZC0wLCwJOCqXdWfClIh/jD/yQitq3ecjp9bvWhV FsWw== Received: by 10.52.34.79 with SMTP id x15mr10532740vdi.0.1336561766655; Wed, 09 May 2012 04:09:26 -0700 (PDT) References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> <-3890923700307571348@unknownmsgid> From: Christoffer Dall In-Reply-To: Mime-Version: 1.0 (1.0) Date: Wed, 9 May 2012 07:09:22 -0400 Message-ID: <5386794781075909369@unknownmsgid> To: Anup Patel X-Gm-Message-State: ALoCoQkHtiK4qioPec+n+s8UgBrE5/KLKncc2LYDOyHJDVHLz9FPsoaVM3N3SNeRs/nNYqk6AeP5 X-Mailman-Approved-At: Tue, 22 May 2012 14:57:47 +0000 Cc: Christoffer Dall , Peter Maydell , "xen-arm@lists.xensource.com" , "android-virt@lists.cs.columbia.edu" , "xen-arm@lists.xen.org" , Xvisor Devel Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7027563077152306247==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============7027563077152306247== Content-Type: multipart/alternative; boundary=20cf3079b82652666904bf98898f --20cf3079b82652666904bf98898f Content-Type: text/plain; charset=ISO-8859-1 On May 9, 2012, at 2:11 AM, Anup Patel wrote: The intention behind the announcement was to inform people interested in virtualization about Xvisor. consider the members og this list informed. The announcement was an early info about achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planning to have scientific paper for Xvisor. Also, I do agree that KVM ARM can be further optimized but as I mentioned in my previous replies "KVM ARM will end-up putting more and more stuff in-kernel". For now you can think of Xvisor ARM = KVM ARM doing everything in-kernel. Even Xvisor ARM is being optimized so, as time passes Xvisor ARM is also going to improve further. Its a common wisdom that "No hypervisor in the world can be better than Native performance". Xvisor ARM is already very very close to native performance and KVM ARM will come close to native performance only by increasing its monolithic nature (i.e. doing more things in-kernel). If monolithic hypervisors are so well performing then why not to have a monolithic hypervisor made for virtualization purpose only. The motivation behind writing Xvisor was the same. Apart from high performance Xvisor has many interesting features such as: *Ability to work without hardware virtualization support* - Xvisor ARM is able to boot multiple unmodified Linux guest even on hosts which do not have virtualization extensions implemented. In contrast, KVM ARM does not work without virtualization extension. The potential number of host hardware that Xvisor ARM can support is much more than KVM ARM can support. Xvisor ARM can in-fact run on old ARMv5 processors too. *Tree-based configuration* - To create a guest we have to just describe the guest in form of a device tree (possible even in runtime). In contrast, for KVM one needs to add the support in QEMU and recompile the binaries. *Pass-through hardware access* - For hardware not accessed or virtualized by Xvisor can be used in pass-through mode. Providing the guests a pass-through accessible device is just matter of adding a tree node and configure irq routing information in guest tree. Its not just PCI devices, we can provide any kind of device as pass-through accessible (Note: if device has in-built DMA then it should have IOMMU or SysMMU otherwise it would be security breach). We have already tried out Serial Port and NIC as pass-through devices. We can compare KVM advantages with Xvisor as follows: *Scheduler* - The linux kernel scheduler is very mature and proven OS scheduler but Hypervisor scheduler can be quite different. Scheduling processes and scheduling VMs can be very different problems. In case of VMs we can use info such as: amount of emulated IO done, amount of time spend in waiting for irq, etc for improving the quality of server consolidation. *Driver base* - Xvisor has and will have all driver framework APIs similar to Linux and driver porting will be just one-on-one replacement of APIs in most cases. *User space tools* - For starter Xvisor will use libvirt tools (or similar open source initiative) for remote management. *Co-existence host processes* - Xvisor is not an OS. Its made for virtualization only so no process. Ofcourse, Xvisor has internal threading framework but most of the time this background threads are sleeping doing nothing. All the management commands are provided by --Anup On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall wrote: > Anup, > > Thanks for providing info on your Xvisor project. However, this is a > mailing list for the development of KVM/ARM and not a scientific forum to > establish in theory which hypervisor "will always perform better than" > which other hypervisor. > > If you want to establish that your code base will always perform better > than all other hosted hypervisors, I strongly encourage you to submit a > paper about this in a peer reviewed conference. Personally I would find > that establishing such facts in a scientific way to be extremely > interesting. > > I understand that you wish to argue Xvisor's superiority in comparison to > KVM, but I disagree with your conclusions. The code path taken in KVM can > be optimized to be extremely short and all logic could be placed within the > KVM module. There are numerous other advantages to using KVM (existing > driver base, upstream kernel integration, compatibility with existing user > space tools, co-existence with native host processes, etc.) and with server > grade hardware I see the reliance on the Linux kernel for scheduling, > memory management etc. to be a great advantage - and not a drawback. On the > other hand, when Xvisor matures, feature requests will only increase its > code size and complexity as well. > > -Christoffer > > On May 6, 2012, at 7:53 AM, Anup Patel wrote: > > Hi PMM, > > Whether to consider model for measuring performance is one's own opinion. > There are number of Tier1 conferences which accept simulation numbers for > proving better approaches provided the simulation platform is well accepted > by everyone. > > Talking about code sequences both Xvisor ARM and KVM ARM have same set of > emulators and drivers. In fact, almost all emulation code has been adopted > from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlike > KVM ARM, in Xvisor ARM there no unnecessary switching between host mode to > guest mode and amount of code traversed in handling any fault is also very > less hence Xvisor-ARM will have much less code executed compared to KVM ARM. > > In Xvisor developement, we have observed that results of any CPU > performance test on QEMU or Fast Model naturally scales up on > real-hardware. Atleast we have never come across any scenario or test > performing better on QEMU or Fast Model compared real-world (this is true > for test running on Native Linux or Linux running as guest on Xvisor ARM). > > In our opinion we strongly believe monolithic approaches are always better > performing over micro-kernelized approaches (or approaches somewhere in > between micro-kernel and monolithic). Hence Xvisor ARM will always perform > better than KVM ARM in theory, simulation and real-world. > > Best Regards, > Anup Patel > > On Sun, May 6, 2012 at 2:21 PM, Peter Maydell wrote: > >> On 6 May 2012 05:22, Anup Patel wrote: >> > Also can you give example of a code sequence which is faster on model >> and >> > slower in real world. As far as I know ARM fast models are internally >> TLM >> > based models and If a TLM based model is emulating a timer chip of X >> clock >> > then it is quite precise X clock. >> >> Support for TLM does not require that the underlying model is cycle >> accurate (you can have 'loosely timed' behaviour). >> >> You might want to read the Fast Models documentation, which tries >> to be clear about what the models do and don't provide. In particular: >> >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html >> "Fast models cannot be used to: >> * model cycle counting >> * model software performance >> " >> >> > Ofcourse CPU emulation and computation >> > power will be less compared to real world. To see this behaviour try to >> boot >> > linux on Fast model or QEMU and leave it for hours and come back see the >> > time elapsed, you will definitely see same amount of time elapsed as >> real >> > world. >> >> Nobody's arguing that the models are faster than hardware! >> Let's try a simple example with some numbers representing >> relative speeds: >> >> operation A: h/w: 1 ; model 5 >> operation B: h/w 3 ; model 30 >> >> Where we're comparing two equivalent code sequences "A A A A" vs "B". >> On hardware "B" will be faster. On the model the "A A A A" beats "B". >> (both sequences are slower on the model than on the hardware, obviously.) >> >> The point is that some operations will be vastly vastly slower >> on the model, and some operations merely moderately slower. Which >> of any two code sequences is fastest depends at least as much on >> whether it's using operations that are disproportionally worse >> on the model. A trivial example of this is VFP -- certainly QEMU >> has to do complex software emulation of the floating point ops to >> maintain bit-for-bit accuracy, which makes them very slow to the >> point where a hand-optimised-integer-assembly codec is likely to >> be faster on the model than a Neon/VFP-using codec, even though >> of course the Neon codec will be faster on hardware. >> >> [NB: this is itself a big simplification: model performance will >> depend on a lot of interacting things and is not purely a >> same-every-time slowdown per operation. Some operations effectively >> slow down what happens after them, for instance on QEMU if you do >> something that makes us flush our cache of translated code. And >> if for instance you have a periodic timer then the fact the model >> is generally slower means you execute proportionally more insns in >> the timer interrupt, so inefficiency or slowness in that code path >> has disproportionately more effect on overall speed than it does >> on hardware. There are other complications too...] >> >> > The results in the announcemnt are not baseless we have quite amount >> reasons >> > to believe Xvisor ARM will perform better than KVM ARM in real-world >> too. >> >> I'm not stating a position on whether KVM will be better or worse >> than Xvisor. I'm just pointing out that you can't base an argument >> on the faulty assumption that performance inside a model can tell >> you anything useful about performance on hardware. >> >> -- PMM >> > > _______________________________________________ > Android-virt mailing list > Android-virt@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > > --20cf3079b82652666904bf98898f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On May 9, 2012, at 2:11 AM, Anup Patel <anup@brainfault.org> wrote:

The intention behind the announcement = was to inform people interested in virtualization about Xvisor.

consider the members og this list informed.=A0
The announcement was an early info about= achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are= planning to have scientific paper for Xvisor.

Also, I do agree that KVM ARM can be further optimized but as I mention= ed in my previous replies "KVM ARM will end-up putting more and more s= tuff in-kernel". For now you can think of Xvisor ARM =3D KVM ARM doing= everything in-kernel. Even Xvisor ARM is being optimized so, as time passe= s Xvisor ARM is also going to improve further. Its a common wisdom that &qu= ot;No hypervisor in the world can be better than Native performance". = Xvisor ARM is already very very close to native performance and KVM ARM wil= l come close to native performance only by increasing its monolithic nature= (i.e. doing more things in-kernel). If monolithic hypervisors are so well = performing then why not to have a monolithic hypervisor made for virtualiza= tion purpose only. The motivation behind writing Xvisor was the same.

Apart from high performance Xvisor has many interesting features such a= s:
Ability to work without hardware virtualization support - Xvis= or ARM is able to boot multiple unmodified Linux guest even on hosts which = do not have virtualization extensions implemented. In contrast, KVM ARM doe= s not work without virtualization extension. The potential number of host h= ardware that Xvisor ARM can support is much more than KVM ARM can support. = Xvisor ARM can in-fact run on old ARMv5 processors too.
Tree-based configuration - To create a guest we have to just describ= e the guest in form of a device tree (possible even in runtime). In contras= t, for KVM one needs to add the support in QEMU and recompile the binaries.=
Pass-through hardware access - For hardware not accessed or virtuali= zed by Xvisor can be used in pass-through mode. Providing the guests a pass= -through accessible device is just matter of adding a tree node and configu= re irq routing information in guest tree. Its not just PCI devices, we can = provide any kind of device as pass-through accessible (Note: if device has = in-built DMA then it should have IOMMU or SysMMU otherwise it would be secu= rity breach). We have already tried out Serial Port and NIC as pass-through= devices.

We can compare KVM advantages with Xvisor as follows:
Scheduler - The linux kernel scheduler is very mature and proven OS scheduler but = Hypervisor scheduler can be quite different. Scheduling processes and sched= uling VMs can be very different problems. In case of VMs we can use info su= ch as: amount of emulated IO done, amount of time spend in waiting for irq,= etc for improving the quality of server consolidation.
Driver base - Xvisor has and will have all driver framework APIs sim= ilar to Linux and driver porting will be just one-on-one replacement of API= s in most cases.
User space tools - For starter Xvisor will use = libvirt tools (or similar open source initiative) for remote management. Co-existence host processes - Xvisor is not an OS. Its made for virt= ualization only so no process. Ofcourse, Xvisor has internal threading fram= ework but most of the time this background threads are sleeping doing nothi= ng. All the management commands are provided by=A0

--Anup

On Wed, May 9, 2012 at 4:29 AM, Christoffer Dall <= cdall@cs.columbia.edu> wrote:

Anup,

Thanks for pro= viding info on your Xvisor project. However, this is a mailing list for the= development of KVM/ARM and not a scientific forum to establish in theory w= hich hypervisor "will always perform better than" which oth= er hypervisor.

If you want to establish that your c= ode base will always perform better than all other hosted hypervisors, I st= rongly encourage you to submit a paper about this in a peer reviewed confer= ence. Personally I would find that establishing such facts in a scientific = way to be extremely interesting.=A0

I understand that you w= ish to argue Xvisor's superiority in comparison to KVM, but I disagree = with your conclusions. The code path taken in KVM can be optimized to be ex= tremely short and all logic could be placed within the KVM module. There ar= e numerous other advantages to using KVM (existing driver base, upstream ke= rnel integration, compatibility with existing user space tools, co-existenc= e with native host processes, etc.) and with server grade hardware I see th= e reliance on the Linux kernel for scheduling, memory management etc. to be= a great advantage - and not a drawback. On the other hand, when Xvisor mat= ures, feature requests will only increase its code size and complexity as w= ell.

-Christoffer

On May 6, 2012, at 7:53 AM, Anup Patel <anup@brainfault.org> w= rote:

Hi PMM,

Whether = to consider model for measuring performance is one's own opinion. There= are number of Tier1 conferences which accept simulation numbers for provin= g better approaches provided the simulation platform is well accepted by ev= eryone.

Talking about code sequences both Xvisor ARM and KVM ARM have same set = of emulators and drivers. In fact, almost all emulation code has been adopt= ed from QEMU. Many of the crucial drivers are adopted from Linux ARM. Unlik= e KVM ARM, in Xvisor ARM=A0 there no unnecessary switching between host mod= e to guest mode and amount of code traversed in handling any fault is also = very less hence Xvisor-ARM will have much less code executed compared to KV= M ARM.

In Xvisor developement, we have observed that results of any CPU perfor= mance test on QEMU or Fast Model naturally scales up on real-hardware. Atle= ast we have never come across any scenario or test performing better on QEM= U or Fast Model compared real-world (this is true for test running on Nativ= e Linux or Linux running as guest on Xvisor ARM).

In our opinion we strongly believe monolithic approaches are always bet= ter performing over micro-kernelized approaches (or approaches somewhere in= between micro-kernel and monolithic). Hence Xvisor ARM will always perform= better than KVM ARM in theory, simulation and real-world.

Best Regards,
Anup Patel

On Sun, M= ay 6, 2012 at 2:21 PM, Peter Maydell <peter.maydell@linaro.org&= gt; wrote:

On 6 May 2012 05:22, Anup Patel <anup@brainfault.org> wrote:
> Also can you give example of a code sequence which is faster on model = and
> slower in real world. As far as I know ARM fast models are internally = TLM
> based models and If a TLM based model is emulating a timer chip of X c= lock
> then it is quite precise X clock.

Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour).

You might want to read the Fast Models documentation, which tries
to be clear about what the models do and don't provide. In particular:<= br> =A0 http://infocenter.arm.com/help/topic/com.ar= m.doc.dui0423l/ch02s01s02.html
"Fast models cannot be used to:
=A0* model cycle counting
=A0* model software performance

"

> Ofcourse CPU emulation and computation
> power will be less compared to real world. To see this behaviour try t= o boot
> linux on Fast model or QEMU and leave it for hours and come back see t= he
> time elapsed, you will definitely see same amount of time elapsed as r= eal
> world.

Nobody's arguing that the models are faster than hardware!
Let's try a simple example with some numbers representing
relative speeds:

=A0operation A: h/w: 1 =A0 =A0; model =A05
=A0operation B: h/w =A03 =A0 =A0; model =A030

Where we're comparing two equivalent code sequences "A A A A"= vs "B".
On hardware "B" will be faster. On the model the "A A A A&qu= ot; beats "B".
(both sequences are slower on the model than on the hardware, obviously.)
The point is that some operations will be vastly vastly slower
on the model, and some operations merely moderately slower. Which
of any two code sequences is fastest depends at least as much on
whether it's using operations that are disproportionally worse
on the model. A trivial example of this is VFP -- certainly QEMU
has to do complex software emulation of the floating point ops to
maintain bit-for-bit accuracy, which makes them very slow to the
point where a hand-optimised-integer-assembly codec is likely to
be faster on the model than a Neon/VFP-using codec, even though
of course the Neon codec will be faster on hardware.

[NB: this is itself a big simplification: model performance will
depend on a lot of interacting things and is not purely a
same-every-time slowdown per operation. Some operations effectively
slow down what happens after them, for instance on QEMU if you do
something that makes us flush our cache of translated code. And
if for instance you have a periodic timer then the fact the model
is generally slower means you execute proportionally more insns in
the timer interrupt, so inefficiency or slowness in that code path
has disproportionately more effect on overall speed than it does
on hardware. There are other complications too...]

> The results in the announcemnt are not baseless we have quite amount r= easons
> to believe Xvisor ARM will perform better than KVM ARM in real-world t= oo.

I'm not stating a position on whether KVM will be better or worse=
than Xvisor. I'm just pointing out that you can't base an argument<= br> on the faulty assumption that performance inside a model can tell
you anything useful about performance on hardware.

-- PMM

_______= ________________________________________
Android-virt maili= ng list
Android-virt@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/and= roid-virt

--20cf3079b82652666904bf98898f-- --===============7027563077152306247== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============7027563077152306247==-- From xen-arm-bounces@lists.xen.org Tue May 22 15:48:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 15:48: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 1SWrK2-0001vL-4A; Tue, 22 May 2012 15:48:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SWrK0-0001vG-VU for xen-arm@lists.xen.org; Tue, 22 May 2012 15:48:29 +0000 Received: from [85.158.143.35:12721] by server-1.bemta-4.messagelabs.com id 82/D0-00342-C45BBBF4; Tue, 22 May 2012 15:48:28 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1337701706!13538405!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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7629 invoked from network); 22 May 2012 15:48:27 -0000 Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com) (209.85.214.45) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 May 2012 15:48:27 -0000 Received: by bkwj10 with SMTP id j10so6272817bkw.32 for ; Tue, 22 May 2012 08:48:26 -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=rY52aLbMxbv1/+va96ro5aknEoYUQch2Xf8neG4U5X8=; b=XSub6Nv9sSJTtV9UlsB9hOfn9hPTRdchiwz38XL2nVYm7e+01guhfyLc6zi/HABtoB iyUOpsveQ/75u7EOVbzd4VspV992ojew4cINDr+vhitgSEIw1ghbuDumSHZb+2DDls6g lNdlggZ/nTlAwSZUVQfobZbShnMh3CHkIQa70WwUrH/63rDNSuHULPF/3NT+ibxHYpM6 1AmnBhuyW6ZWeiEWkxcCGIMcXWymOfW4Gym6KGHq8aQdHDvoRDY50DlIa6NO7L3Ytn9Q 7B82ssBL9SVKd6DMkrpTouS7QSszzoiiMbnTz40WQA4QpcBwhT+jlHrBK89J6h3GawLJ reWg== Received: by 10.204.152.132 with SMTP id g4mr10629716bkw.88.1337701706014; Tue, 22 May 2012 08:48:26 -0700 (PDT) Received: from [172.16.25.10] (b0fb6af0.bb.sky.com. [176.251.106.240]) by mx.google.com with ESMTPS id u8sm33014328bks.0.2012.05.22.08.48.23 (version=SSLv3 cipher=OTHER); Tue, 22 May 2012 08:48:24 -0700 (PDT) Message-ID: <4FBBB546.1040509@xen.org> Date: Tue, 22 May 2012 16:48:22 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen-arm@lists.xen.org, anup@brainfault.org References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> <-3890923700307571348@unknownmsgid> <-6403728154748147809@unknownmsgid> In-Reply-To: <-6403728154748147809@unknownmsgid> Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Lars Kurth List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1090379991762914001==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org This is a multi-part message in MIME format. --===============1090379991762914001== Content-Type: multipart/alternative; boundary="------------000807020101050405010906" This is a multi-part message in MIME format. --------------000807020101050405010906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/05/2012 12:16, Christoffer Dall wrote: > > On May 9, 2012, at 2:11 AM, Anup Patel > wrote: > >> The intention behind the announcement was to inform people interested >> in virtualization about Xvisor. The announcement was an early info >> about achievements of Xvisor ARM (for now compared to KVM ARM). >> Certainly we are planning to have scientific paper for Xvisor. >> > consider the members of this list informed > We don't normally ban people from our lists, but we will do so if the community feels this to be a nuisance. I think Christoffer has made his viewpoint clear and I have had complaints from others too. This is not the right place to discuss details of a project that is not directly related to Xen. Best Regards Lars --------------000807020101050405010906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/05/2012 12:16, Christoffer Dall wrote:

On May 9, 2012, at 2:11 AM, Anup Patel <anup@brainfault.org> wrote:

The intention behind the announcement was to inform people interested in virtualization about Xvisor. The announcement was an early info about achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planning to have scientific paper for Xvisor.

consider the members of this list informed

We don't normally ban people from our lists, but we will do so if the community feels this to be a nuisance.

I think Christoffer has made his viewpoint clear and I have had complaints from others too. This is not the right place to discuss details of a project that is not directly related to Xen.

Best Regards
Lars

--------------000807020101050405010906-- --===============1090379991762914001== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============1090379991762914001==-- From xen-arm-bounces@lists.xen.org Tue May 22 15:48:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 May 2012 15:48: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 1SWrK2-0001vL-4A; Tue, 22 May 2012 15:48:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SWrK0-0001vG-VU for xen-arm@lists.xen.org; Tue, 22 May 2012 15:48:29 +0000 Received: from [85.158.143.35:12721] by server-1.bemta-4.messagelabs.com id 82/D0-00342-C45BBBF4; Tue, 22 May 2012 15:48:28 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1337701706!13538405!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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7629 invoked from network); 22 May 2012 15:48:27 -0000 Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com) (209.85.214.45) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 May 2012 15:48:27 -0000 Received: by bkwj10 with SMTP id j10so6272817bkw.32 for ; Tue, 22 May 2012 08:48:26 -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=rY52aLbMxbv1/+va96ro5aknEoYUQch2Xf8neG4U5X8=; b=XSub6Nv9sSJTtV9UlsB9hOfn9hPTRdchiwz38XL2nVYm7e+01guhfyLc6zi/HABtoB iyUOpsveQ/75u7EOVbzd4VspV992ojew4cINDr+vhitgSEIw1ghbuDumSHZb+2DDls6g lNdlggZ/nTlAwSZUVQfobZbShnMh3CHkIQa70WwUrH/63rDNSuHULPF/3NT+ibxHYpM6 1AmnBhuyW6ZWeiEWkxcCGIMcXWymOfW4Gym6KGHq8aQdHDvoRDY50DlIa6NO7L3Ytn9Q 7B82ssBL9SVKd6DMkrpTouS7QSszzoiiMbnTz40WQA4QpcBwhT+jlHrBK89J6h3GawLJ reWg== Received: by 10.204.152.132 with SMTP id g4mr10629716bkw.88.1337701706014; Tue, 22 May 2012 08:48:26 -0700 (PDT) Received: from [172.16.25.10] (b0fb6af0.bb.sky.com. [176.251.106.240]) by mx.google.com with ESMTPS id u8sm33014328bks.0.2012.05.22.08.48.23 (version=SSLv3 cipher=OTHER); Tue, 22 May 2012 08:48:24 -0700 (PDT) Message-ID: <4FBBB546.1040509@xen.org> Date: Tue, 22 May 2012 16:48:22 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen-arm@lists.xen.org, anup@brainfault.org References: <20120505161436.0a64fd33@taxman.wild-wind.fr.eu.org> <-3890923700307571348@unknownmsgid> <-6403728154748147809@unknownmsgid> In-Reply-To: <-6403728154748147809@unknownmsgid> Subject: Re: [XenARM] [Android-virt] [ANNOUNCE] Xvisor ARM better than KVM ARM in CPU virtualization X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Lars Kurth List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1090379991762914001==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org This is a multi-part message in MIME format. --===============1090379991762914001== Content-Type: multipart/alternative; boundary="------------000807020101050405010906" This is a multi-part message in MIME format. --------------000807020101050405010906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/05/2012 12:16, Christoffer Dall wrote: > > On May 9, 2012, at 2:11 AM, Anup Patel > wrote: > >> The intention behind the announcement was to inform people interested >> in virtualization about Xvisor. The announcement was an early info >> about achievements of Xvisor ARM (for now compared to KVM ARM). >> Certainly we are planning to have scientific paper for Xvisor. >> > consider the members of this list informed > We don't normally ban people from our lists, but we will do so if the community feels this to be a nuisance. I think Christoffer has made his viewpoint clear and I have had complaints from others too. This is not the right place to discuss details of a project that is not directly related to Xen. Best Regards Lars --------------000807020101050405010906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/05/2012 12:16, Christoffer Dall wrote:

On May 9, 2012, at 2:11 AM, Anup Patel <anup@brainfault.org> wrote:

The intention behind the announcement was to inform people interested in virtualization about Xvisor. The announcement was an early info about achievements of Xvisor ARM (for now compared to KVM ARM). Certainly we are planning to have scientific paper for Xvisor.

consider the members of this list informed

We don't normally ban people from our lists, but we will do so if the community feels this to be a nuisance.

I think Christoffer has made his viewpoint clear and I have had complaints from others too. This is not the right place to discuss details of a project that is not directly related to Xen.

Best Regards
Lars

--------------000807020101050405010906-- --===============1090379991762914001== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============1090379991762914001==-- From xen-arm-bounces@lists.xen.org Wed May 23 10:37:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 May 2012 10: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 1SX8wf-0004ZC-5l; Wed, 23 May 2012 10:37:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SX8we-0004Z7-9V for xen-arm@lists.xen.org; Wed, 23 May 2012 10:37:32 +0000 Received: from [85.158.143.99:19817] by server-3.bemta-4.messagelabs.com id 12/29-05853-BEDBCBF4; Wed, 23 May 2012 10:37:31 +0000 X-Env-Sender: maryjoy883@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1337769449!28832394!1 X-Originating-IP: [209.85.213.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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22215 invoked from network); 23 May 2012 10:37:30 -0000 Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com) (209.85.213.45) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 May 2012 10:37:30 -0000 Received: by yhoo21 with SMTP id o21so7763457yho.32 for ; Wed, 23 May 2012 03:37:29 -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=kfgNTORh10b8v0ilpAXEuGFvO1qdkCEVGvzAnE3Ip4M=; b=lzP8+yAYYKMcSYA2qVz6WUQEvEYrNhMQyxMA/jq9AgQut2z34TW0GxyhAnBhI+PWCH U4yC4Q5+2XK/gqojYqZnrwb+XrLgrPV977p/i3bmBQvmXqOjQDJ/lN/O3l/P5S5HzxSz ndqnxTAg/eCwDUumjvbuIcZXQWC7cO2SvS5aWfgfcRekV5xXfNtiq1ytWJ9VTg8Er0e1 1BlkErpfZqvd+MCX+qzyf+3TchnftcEjYtZYxdGQmlYBWSfoC/MtA1NcyYM2WR55BCYS bbYmvV6kEGIkXsoMoGpwJdk/EyY6ugwsVijYY8q287QIqaeInhzLZP53m/w64eaUQBKw jJww== Received: by 10.50.140.5 with SMTP id rc5mr12569132igb.40.1337769448983; Wed, 23 May 2012 03:37:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.95.138 with HTTP; Wed, 23 May 2012 03:37:08 -0700 (PDT) From: mabel mary joy Date: Wed, 23 May 2012 12:37:08 +0200 Message-ID: To: xen-arm@lists.xen.org Subject: [XenARM] The Qemu window doesn't open X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5443917764281019034==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============5443917764281019034== Content-Type: multipart/alternative; boundary=e89a8f83a34bcc4c5204c0b1b823 --e89a8f83a34bcc4c5204c0b1b823 Content-Type: text/plain; charset=ISO-8859-1 Hi I was able to compile the tool qemu-xen_arm-081120.tar.bz2 When the script run.sh is executed. it show the following messages guest0-mini-os guest1-mini-os Waiting gdb connection on port 1234 emulator: control console listening on port 5554, ADB on port 5555 emulator: can't connect to ADB server: errno 111: Connection refused emulator: ping program: /home/mabel/xen_arm/android-emulator-xen_arm/ddms But it doesnt open any qemu / emulation window after that. Is there something to be done in order to get the window opened and running mini-os? -- Regards Mabel --e89a8f83a34bcc4c5204c0b1b823 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi

I was able to compile the tool qemu-xen_arm-081120.tar.bz2
When the script run.sh is executed. it show the following messages

= guest0-mini-os
guest1-mini-os
Waiting gdb connection on port 1234
emulator: control console= listening on port 5554, ADB on port 5555
emul= ator: can't connect to ADB server: errno 111: Connection refused=
emulator: ping program: /home/mabel/xen_arm/android-emulator-xen_arm/ddms

But i= t doesnt open any qemu / emulation window after that.

Is there somet= hing to be done in order to get the window opened and running mini-os?

--
Regards
Mabel
--e89a8f83a34bcc4c5204c0b1b823-- --===============5443917764281019034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============5443917764281019034==-- From xen-arm-bounces@lists.xen.org Wed May 23 10:37:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 May 2012 10: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 1SX8wf-0004ZC-5l; Wed, 23 May 2012 10:37:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SX8we-0004Z7-9V for xen-arm@lists.xen.org; Wed, 23 May 2012 10:37:32 +0000 Received: from [85.158.143.99:19817] by server-3.bemta-4.messagelabs.com id 12/29-05853-BEDBCBF4; Wed, 23 May 2012 10:37:31 +0000 X-Env-Sender: maryjoy883@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1337769449!28832394!1 X-Originating-IP: [209.85.213.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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22215 invoked from network); 23 May 2012 10:37:30 -0000 Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com) (209.85.213.45) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 May 2012 10:37:30 -0000 Received: by yhoo21 with SMTP id o21so7763457yho.32 for ; Wed, 23 May 2012 03:37:29 -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=kfgNTORh10b8v0ilpAXEuGFvO1qdkCEVGvzAnE3Ip4M=; b=lzP8+yAYYKMcSYA2qVz6WUQEvEYrNhMQyxMA/jq9AgQut2z34TW0GxyhAnBhI+PWCH U4yC4Q5+2XK/gqojYqZnrwb+XrLgrPV977p/i3bmBQvmXqOjQDJ/lN/O3l/P5S5HzxSz ndqnxTAg/eCwDUumjvbuIcZXQWC7cO2SvS5aWfgfcRekV5xXfNtiq1ytWJ9VTg8Er0e1 1BlkErpfZqvd+MCX+qzyf+3TchnftcEjYtZYxdGQmlYBWSfoC/MtA1NcyYM2WR55BCYS bbYmvV6kEGIkXsoMoGpwJdk/EyY6ugwsVijYY8q287QIqaeInhzLZP53m/w64eaUQBKw jJww== Received: by 10.50.140.5 with SMTP id rc5mr12569132igb.40.1337769448983; Wed, 23 May 2012 03:37:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.95.138 with HTTP; Wed, 23 May 2012 03:37:08 -0700 (PDT) From: mabel mary joy Date: Wed, 23 May 2012 12:37:08 +0200 Message-ID: To: xen-arm@lists.xen.org Subject: [XenARM] The Qemu window doesn't open X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5443917764281019034==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============5443917764281019034== Content-Type: multipart/alternative; boundary=e89a8f83a34bcc4c5204c0b1b823 --e89a8f83a34bcc4c5204c0b1b823 Content-Type: text/plain; charset=ISO-8859-1 Hi I was able to compile the tool qemu-xen_arm-081120.tar.bz2 When the script run.sh is executed. it show the following messages guest0-mini-os guest1-mini-os Waiting gdb connection on port 1234 emulator: control console listening on port 5554, ADB on port 5555 emulator: can't connect to ADB server: errno 111: Connection refused emulator: ping program: /home/mabel/xen_arm/android-emulator-xen_arm/ddms But it doesnt open any qemu / emulation window after that. Is there something to be done in order to get the window opened and running mini-os? -- Regards Mabel --e89a8f83a34bcc4c5204c0b1b823 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi

I was able to compile the tool qemu-xen_arm-081120.tar.bz2
When the script run.sh is executed. it show the following messages

= guest0-mini-os
guest1-mini-os
Waiting gdb connection on port 1234
emulator: control console= listening on port 5554, ADB on port 5555
emul= ator: can't connect to ADB server: errno 111: Connection refused=
emulator: ping program: /home/mabel/xen_arm/android-emulator-xen_arm/ddms

But i= t doesnt open any qemu / emulation window after that.

Is there somet= hing to be done in order to get the window opened and running mini-os?

--
Regards
Mabel
--e89a8f83a34bcc4c5204c0b1b823-- --===============5443917764281019034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============5443917764281019034==-- From xen-arm-bounces@lists.xen.org Wed May 23 10:57:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 May 2012 10:57: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 1SX9Fw-0005CN-Rf; Wed, 23 May 2012 10:57:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SX9Fv-0005C6-1w for xen-arm@lists.xen.org; Wed, 23 May 2012 10:57:27 +0000 Received: from [85.158.143.35:32834] by server-1.bemta-4.messagelabs.com id C1/85-00342-692CCBF4; Wed, 23 May 2012 10:57:26 +0000 X-Env-Sender: post4pavan@gmail.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1337770641!15596788!1 X-Originating-IP: [209.85.160.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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1913 invoked from network); 23 May 2012 10:57:22 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 23 May 2012 10:57:22 -0000 Received: by ghrr14 with SMTP id r14so1446863ghr.32 for ; Wed, 23 May 2012 03:57: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=1YCmr/TNqfz8wHfteB6xYBLHYmPkRaMgVOzLyT3yLUk=; b=cHLt8/vGkCKdiqFkDFZVShGDeff/xeEZMLk532vFNgIvk1SejME5ZybKaCbbjWCSKb 7E5ZrCQilNUZLQicFpJCvf27arq0GpD1CAjTvH/TMWFpC9pzfc9siRM+865ZJGOyzUgT JC4NzULPqPIoRrBr6Q2FeFw8nC1VL+Y+WpdeYeEvNfdiBR6kwKjbhqNCWYerNbUExQDU wrYYe7YcVxACIF4kS9SrgcDZ+hNORzIROiGBAr6q4xa97m67RQ4QrZyyrCXQcB7vhYBU QFlCGehv1UhA4kIy1FCGEZW94uhlCQPYBMTVRmIJdRkoe7a/DJat3XCESPYelB5GsUd4 fv9A== MIME-Version: 1.0 Received: by 10.50.42.196 with SMTP id q4mr12570690igl.28.1337770640534; Wed, 23 May 2012 03:57:20 -0700 (PDT) Received: by 10.42.241.131 with HTTP; Wed, 23 May 2012 03:57:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 May 2012 16:27:20 +0530 Message-ID: From: Krishna Pavan To: xen-arm@lists.xen.org Cc: mabel mary joy Subject: Re: [XenARM] The Qemu window doesn't open X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9109661375601623983==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============9109661375601623983== Content-Type: multipart/alternative; boundary=bcaec5396c60d1ec6604c0b1fff4 --bcaec5396c60d1ec6604c0b1fff4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Xen-ARM, even I ended up with the same error. * Has anyone worked with the android-xen-arm and has any one succeeded with that?* The script used is ./emulator -verbose -guest0 0x01c00000 mini-os.elf -guest1 0x02c00000 mini-os.elf -show-kernel -system ./images -shell -qemu -s -kernel xen Where kernel xen is the Xen ELF image used. and the file loaded in the gdb [opened in another terminal window is mini-os.elf @ port : 1234] Procedure I followed in gdb is file mini-os.elf target remote localhost:1234 post4pavan@ubuntu:~/Downloads/QEMU/android-emulator-xen_arm$ ./run-pavan.sh guest0 - mini-os.elf guest1 - mini-os.elf emulator: autoconfig: -datadir /home/post4pavan/.android emulator: autoconfig: -kernel ./images/kernel-qemu emulator: autoconfig: -ramdisk ./images/ramdisk.img emulator: autoconfig: -image ./images/system.img emulator: autoconfig: -initdata ./images/userdata.img emulator: autoconfig: -skindir ./images/skins emulator: autoconfig: -sdcard /home/post4pavan/.android/sdcard.img emulator: autoconfig: -data /home/post4pavan/.android/userdata.img emulator: autoconfig: -data /home/post4pavan/.android/userdata-qemu.img emulator: parsing built-in skin layout file (size=3D7714) emulator: skin network speed: 'full' emulator: skin network delay: 'none' emulator: argv[00] =3D "./emulator" emulator: argv[01] =3D "-kernel" emulator: argv[02] =3D "./images/kernel-qemu" emulator: argv[03] =3D "-guest0" emulator: argv[04] =3D "0x01c00000" emulator: argv[05] =3D "mini-os.elf" emulator: argv[06] =3D "-guest1" emulator: argv[07] =3D "0x02c00000" emulator: argv[08] =3D "mini-os.elf" emulator: argv[09] =3D "-initrd" emulator: argv[10] =3D "./images/ramdisk.img" emulator: argv[11] =3D "-nand" emulator: argv[12] =3D "system,size=3D0x4200000,initfile=3D./images/system.= img" emulator: argv[13] =3D "-nand" emulator: argv[14] =3D "userdata,size=3D0x4200000,file=3D/home/post4pavan/.android/userdata-qemu.i= mg" emulator: argv[15] =3D "-nand" emulator: argv[16] =3D "cache,size=3D0x4200000" emulator: argv[17] =3D "-serial" emulator: argv[18] =3D "android-kmsg" emulator: argv[19] =3D "-serial" emulator: argv[20] =3D "stdio" emulator: argv[21] =3D "-serial" emulator: argv[22] =3D "android-qemud" emulator: argv[23] =3D "-append" emulator: argv[24] =3D "qemu=3D1 console=3DttyS0 androidboot.console=3DttyS= 1 android.checkjni=3D1 android.qemud=3DttyS2 android.ndns=3D2" emulator: argv[25] =3D "-s" emulator: argv[26] =3D "-kernel" emulator: argv[27] =3D "xen" emulator: template: /tmp/android/emulator-XXXXXX emulator: mapping 'system' NAND image to /tmp/android/emulator-RKNjcS emulator: template: /tmp/android/emulator-XXXXXX emulator: mapping 'cache' NAND image to /tmp/android/emulator-TSr3hp emulator: using 'unix' alarm timer emulator: using 'esd' audio input backend emulator: using 'esd' audio output backend Waiting gdb connection on port 1234 emulator: control console listening on port 5554, ADB on port 5555 emulator: can't connect to ADB server: errno 111: Connection refused emulator: ping program: /home/post4pavan/Downloads/QEMU/android-emulator-xen_arm/ddms Hi > > I was able to compile the tool qemu-xen_arm-081120.tar.bz2 > > When the script run.sh is executed. it show the following messages > > guest0-mini-os > guest1-mini-os > Waiting gdb connection on port 1234 > emulator: control console listening on port 5554, ADB on port 5555 > emulator: can't connect to ADB server: errno 111: Connection refused > emulator: ping program: /home/mabel/xen_arm/android- emulator-xen_arm/ddm= s > > But it doesnt open any qemu / emulation window after that. > > Is there something to be done in order to get the window opened and > running mini-os? > --=20 =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D --bcaec5396c60d1ec6604c0b1fff4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Xe= n-ARM, even I e= nded up with the same error.

Has anyone worked with the android-xen-arm and has any one succeeded with t= hat?

The script used is

./emulator -verbose -guest0= 0x01c00000 mini-os.elf -guest1 0x02c00000 mini-os.elf -show-kernel -system= ./images -shell -qemu -s -kernel xen

Where kernel xen is the Xen ELF image used.

and the file loaded in= the gdb [opened in another terminal window is mini-os.elf @ port : 1234]
Procedure I followed in gdb is

file min= i-os.elf
tar= get remote localhost:1234

post4pavan@ubuntu:~/Downloads/QEMU/an= droid-emulator-xen_arm$ ./run-pavan.sh
guest0 - mini-os.elf
guest1 - mini-os.elf
emulator: autoconfig: -data= dir /home/post4pavan/.android
emulator: autoconfig: -kernel ./images/ker= nel-qemu
emulator: autoconfig: -ramdisk ./images/ramdisk.img
emulator= : autoconfig: -image ./images/system.img
emulator: autoconfig: -initdata ./images/userdata.img
emulator: autoconf= ig: -skindir ./images/skins
emulator: autoconfig: -sdcard /home/post4pav= an/.android/sdcard.img
emulator: autoconfig: -data /home/post4pavan/.and= roid/userdata.img
emulator: autoconfig: -data /home/post4pavan/.android/userdata-qemu.img
= emulator: parsing built-in skin layout file (size=3D7714)
emulator: skin= network speed: 'full'
emulator: skin network delay: 'none&#= 39;
emulator: argv[00] =3D "./emulator"
emulator: argv[01] =3D &qu= ot;-kernel"
emulator: argv[02] =3D "./images/kernel-qemu"=
emulator: argv[03] =3D "-guest0"
emulator: argv[04] =3D &q= uot;0x01c00000"
emulator: argv[05] =3D "mini-os.elf"
emulator: argv[06] =3D &q= uot;-guest1"
emulator: argv[07] =3D "0x02c00000"
emula= tor: argv[08] =3D "mini-os.elf"
emulator: argv[09] =3D "-= initrd"
emulator: argv[10] =3D "./images/ramdisk.img"
emulator: argv[1= 1] =3D "-nand"
emulator: argv[12] =3D "system,size=3D0x42= 00000,initfile=3D./images/system.img"
emulator: argv[13] =3D "= -nand"
emulator: argv[14] =3D "userdata,size=3D0x4200000,file=3D/home/post4pa= van/.android/userdata-qemu.img"
emulator: argv[15] =3D "-nand&= quot;
emulator: argv[16] =3D "cache,size=3D0x4200000"
emula= tor: argv[17] =3D "-serial"
emulator: argv[18] =3D "android-kmsg"
emulator: argv[19] =3D &= quot;-serial"
emulator: argv[20] =3D "stdio"
emulator:= argv[21] =3D "-serial"
emulator: argv[22] =3D "android-q= emud"
emulator: argv[23] =3D "-append"
emulator: argv[24] =3D "= qemu=3D1 console=3DttyS0 androidboot.console=3DttyS1 android.checkjni=3D1 a= ndroid.qemud=3DttyS2 android.ndns=3D2"
emulator: argv[25] =3D "= ;-s"
emulator: argv[26] =3D "-kernel"
emulator: argv[27] =3D "xen"
emulator: template: /tmp/android/= emulator-XXXXXX
emulator: mapping 'system' NAND image to /tmp/an= droid/emulator-RKNjcS
emulator: template: /tmp/android/emulator-XXXXXX emulator: mapping 'cache' NAND image to /tmp/android/emulator-TSr3h= p
emulator: using 'unix' alarm timer
emulator: using 'esd= ' audio input backend
emulator: using 'esd' audio output bac= kend
Waiting gdb connection on port 1234
emulator: control console listening = on port 5554, ADB on port 5555
emulator: can't connect to ADB server= : errno 111: Connection refused
emulator: ping program: /home/post4pavan= /Downloads/QEMU/android-emulator-xen_arm/ddms

Hi

I was able to compile the tool qemu-xen_arm-0811= 20.tar.bz2

When the script run.sh is executed. it show the following messages
<= br>guest0-mini-os<= br style=3D"font-family:times new roman,serif">guest1-mini-os
Waiting gdb connection on port 1234
emulator: control console listening on port 5554,= ADB on port 5555
emulator: can't connect to ADB serv= er: errno 111: Connection refused
emulator: ping program: /home/mabel/xen_arm/android- emulator-xen= _arm/ddms

But it doesnt open any qemu / emulation window afte= r that.

Is there something to be done in order to get the window ope= ned and running mini-os?

--
=E2=9C=89 Regards :: Kri= shna Pavan =E2=9C=8D

--bcaec5396c60d1ec6604c0b1fff4-- --===============9109661375601623983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============9109661375601623983==-- From xen-arm-bounces@lists.xen.org Wed May 23 10:57:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 May 2012 10:57: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 1SX9Fw-0005CN-Rf; Wed, 23 May 2012 10:57:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SX9Fv-0005C6-1w for xen-arm@lists.xen.org; Wed, 23 May 2012 10:57:27 +0000 Received: from [85.158.143.35:32834] by server-1.bemta-4.messagelabs.com id C1/85-00342-692CCBF4; Wed, 23 May 2012 10:57:26 +0000 X-Env-Sender: post4pavan@gmail.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1337770641!15596788!1 X-Originating-IP: [209.85.160.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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1913 invoked from network); 23 May 2012 10:57:22 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 23 May 2012 10:57:22 -0000 Received: by ghrr14 with SMTP id r14so1446863ghr.32 for ; Wed, 23 May 2012 03:57: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=1YCmr/TNqfz8wHfteB6xYBLHYmPkRaMgVOzLyT3yLUk=; b=cHLt8/vGkCKdiqFkDFZVShGDeff/xeEZMLk532vFNgIvk1SejME5ZybKaCbbjWCSKb 7E5ZrCQilNUZLQicFpJCvf27arq0GpD1CAjTvH/TMWFpC9pzfc9siRM+865ZJGOyzUgT JC4NzULPqPIoRrBr6Q2FeFw8nC1VL+Y+WpdeYeEvNfdiBR6kwKjbhqNCWYerNbUExQDU wrYYe7YcVxACIF4kS9SrgcDZ+hNORzIROiGBAr6q4xa97m67RQ4QrZyyrCXQcB7vhYBU QFlCGehv1UhA4kIy1FCGEZW94uhlCQPYBMTVRmIJdRkoe7a/DJat3XCESPYelB5GsUd4 fv9A== MIME-Version: 1.0 Received: by 10.50.42.196 with SMTP id q4mr12570690igl.28.1337770640534; Wed, 23 May 2012 03:57:20 -0700 (PDT) Received: by 10.42.241.131 with HTTP; Wed, 23 May 2012 03:57:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 May 2012 16:27:20 +0530 Message-ID: From: Krishna Pavan To: xen-arm@lists.xen.org Cc: mabel mary joy Subject: Re: [XenARM] The Qemu window doesn't open X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9109661375601623983==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============9109661375601623983== Content-Type: multipart/alternative; boundary=bcaec5396c60d1ec6604c0b1fff4 --bcaec5396c60d1ec6604c0b1fff4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Xen-ARM, even I ended up with the same error. * Has anyone worked with the android-xen-arm and has any one succeeded with that?* The script used is ./emulator -verbose -guest0 0x01c00000 mini-os.elf -guest1 0x02c00000 mini-os.elf -show-kernel -system ./images -shell -qemu -s -kernel xen Where kernel xen is the Xen ELF image used. and the file loaded in the gdb [opened in another terminal window is mini-os.elf @ port : 1234] Procedure I followed in gdb is file mini-os.elf target remote localhost:1234 post4pavan@ubuntu:~/Downloads/QEMU/android-emulator-xen_arm$ ./run-pavan.sh guest0 - mini-os.elf guest1 - mini-os.elf emulator: autoconfig: -datadir /home/post4pavan/.android emulator: autoconfig: -kernel ./images/kernel-qemu emulator: autoconfig: -ramdisk ./images/ramdisk.img emulator: autoconfig: -image ./images/system.img emulator: autoconfig: -initdata ./images/userdata.img emulator: autoconfig: -skindir ./images/skins emulator: autoconfig: -sdcard /home/post4pavan/.android/sdcard.img emulator: autoconfig: -data /home/post4pavan/.android/userdata.img emulator: autoconfig: -data /home/post4pavan/.android/userdata-qemu.img emulator: parsing built-in skin layout file (size=3D7714) emulator: skin network speed: 'full' emulator: skin network delay: 'none' emulator: argv[00] =3D "./emulator" emulator: argv[01] =3D "-kernel" emulator: argv[02] =3D "./images/kernel-qemu" emulator: argv[03] =3D "-guest0" emulator: argv[04] =3D "0x01c00000" emulator: argv[05] =3D "mini-os.elf" emulator: argv[06] =3D "-guest1" emulator: argv[07] =3D "0x02c00000" emulator: argv[08] =3D "mini-os.elf" emulator: argv[09] =3D "-initrd" emulator: argv[10] =3D "./images/ramdisk.img" emulator: argv[11] =3D "-nand" emulator: argv[12] =3D "system,size=3D0x4200000,initfile=3D./images/system.= img" emulator: argv[13] =3D "-nand" emulator: argv[14] =3D "userdata,size=3D0x4200000,file=3D/home/post4pavan/.android/userdata-qemu.i= mg" emulator: argv[15] =3D "-nand" emulator: argv[16] =3D "cache,size=3D0x4200000" emulator: argv[17] =3D "-serial" emulator: argv[18] =3D "android-kmsg" emulator: argv[19] =3D "-serial" emulator: argv[20] =3D "stdio" emulator: argv[21] =3D "-serial" emulator: argv[22] =3D "android-qemud" emulator: argv[23] =3D "-append" emulator: argv[24] =3D "qemu=3D1 console=3DttyS0 androidboot.console=3DttyS= 1 android.checkjni=3D1 android.qemud=3DttyS2 android.ndns=3D2" emulator: argv[25] =3D "-s" emulator: argv[26] =3D "-kernel" emulator: argv[27] =3D "xen" emulator: template: /tmp/android/emulator-XXXXXX emulator: mapping 'system' NAND image to /tmp/android/emulator-RKNjcS emulator: template: /tmp/android/emulator-XXXXXX emulator: mapping 'cache' NAND image to /tmp/android/emulator-TSr3hp emulator: using 'unix' alarm timer emulator: using 'esd' audio input backend emulator: using 'esd' audio output backend Waiting gdb connection on port 1234 emulator: control console listening on port 5554, ADB on port 5555 emulator: can't connect to ADB server: errno 111: Connection refused emulator: ping program: /home/post4pavan/Downloads/QEMU/android-emulator-xen_arm/ddms Hi > > I was able to compile the tool qemu-xen_arm-081120.tar.bz2 > > When the script run.sh is executed. it show the following messages > > guest0-mini-os > guest1-mini-os > Waiting gdb connection on port 1234 > emulator: control console listening on port 5554, ADB on port 5555 > emulator: can't connect to ADB server: errno 111: Connection refused > emulator: ping program: /home/mabel/xen_arm/android- emulator-xen_arm/ddm= s > > But it doesnt open any qemu / emulation window after that. > > Is there something to be done in order to get the window opened and > running mini-os? > --=20 =E2=9C=89 Regards :: Krishna Pavan =E2=9C=8D --bcaec5396c60d1ec6604c0b1fff4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Xe= n-ARM, even I e= nded up with the same error.

Has anyone worked with the android-xen-arm and has any one succeeded with t= hat?

The script used is

./emulator -verbose -guest0= 0x01c00000 mini-os.elf -guest1 0x02c00000 mini-os.elf -show-kernel -system= ./images -shell -qemu -s -kernel xen

Where kernel xen is the Xen ELF image used.

and the file loaded in= the gdb [opened in another terminal window is mini-os.elf @ port : 1234]
Procedure I followed in gdb is

file min= i-os.elf
tar= get remote localhost:1234

post4pavan@ubuntu:~/Downloads/QEMU/an= droid-emulator-xen_arm$ ./run-pavan.sh
guest0 - mini-os.elf
guest1 - mini-os.elf
emulator: autoconfig: -data= dir /home/post4pavan/.android
emulator: autoconfig: -kernel ./images/ker= nel-qemu
emulator: autoconfig: -ramdisk ./images/ramdisk.img
emulator= : autoconfig: -image ./images/system.img
emulator: autoconfig: -initdata ./images/userdata.img
emulator: autoconf= ig: -skindir ./images/skins
emulator: autoconfig: -sdcard /home/post4pav= an/.android/sdcard.img
emulator: autoconfig: -data /home/post4pavan/.and= roid/userdata.img
emulator: autoconfig: -data /home/post4pavan/.android/userdata-qemu.img
= emulator: parsing built-in skin layout file (size=3D7714)
emulator: skin= network speed: 'full'
emulator: skin network delay: 'none&#= 39;
emulator: argv[00] =3D "./emulator"
emulator: argv[01] =3D &qu= ot;-kernel"
emulator: argv[02] =3D "./images/kernel-qemu"=
emulator: argv[03] =3D "-guest0"
emulator: argv[04] =3D &q= uot;0x01c00000"
emulator: argv[05] =3D "mini-os.elf"
emulator: argv[06] =3D &q= uot;-guest1"
emulator: argv[07] =3D "0x02c00000"
emula= tor: argv[08] =3D "mini-os.elf"
emulator: argv[09] =3D "-= initrd"
emulator: argv[10] =3D "./images/ramdisk.img"
emulator: argv[1= 1] =3D "-nand"
emulator: argv[12] =3D "system,size=3D0x42= 00000,initfile=3D./images/system.img"
emulator: argv[13] =3D "= -nand"
emulator: argv[14] =3D "userdata,size=3D0x4200000,file=3D/home/post4pa= van/.android/userdata-qemu.img"
emulator: argv[15] =3D "-nand&= quot;
emulator: argv[16] =3D "cache,size=3D0x4200000"
emula= tor: argv[17] =3D "-serial"
emulator: argv[18] =3D "android-kmsg"
emulator: argv[19] =3D &= quot;-serial"
emulator: argv[20] =3D "stdio"
emulator:= argv[21] =3D "-serial"
emulator: argv[22] =3D "android-q= emud"
emulator: argv[23] =3D "-append"
emulator: argv[24] =3D "= qemu=3D1 console=3DttyS0 androidboot.console=3DttyS1 android.checkjni=3D1 a= ndroid.qemud=3DttyS2 android.ndns=3D2"
emulator: argv[25] =3D "= ;-s"
emulator: argv[26] =3D "-kernel"
emulator: argv[27] =3D "xen"
emulator: template: /tmp/android/= emulator-XXXXXX
emulator: mapping 'system' NAND image to /tmp/an= droid/emulator-RKNjcS
emulator: template: /tmp/android/emulator-XXXXXX emulator: mapping 'cache' NAND image to /tmp/android/emulator-TSr3h= p
emulator: using 'unix' alarm timer
emulator: using 'esd= ' audio input backend
emulator: using 'esd' audio output bac= kend
Waiting gdb connection on port 1234
emulator: control console listening = on port 5554, ADB on port 5555
emulator: can't connect to ADB server= : errno 111: Connection refused
emulator: ping program: /home/post4pavan= /Downloads/QEMU/android-emulator-xen_arm/ddms

Hi

I was able to compile the tool qemu-xen_arm-0811= 20.tar.bz2

When the script run.sh is executed. it show the following messages
<= br>guest0-mini-os<= br style=3D"font-family:times new roman,serif">guest1-mini-os
Waiting gdb connection on port 1234
emulator: control console listening on port 5554,= ADB on port 5555
emulator: can't connect to ADB serv= er: errno 111: Connection refused
emulator: ping program: /home/mabel/xen_arm/android- emulator-xen= _arm/ddms

But it doesnt open any qemu / emulation window afte= r that.

Is there something to be done in order to get the window ope= ned and running mini-os?

--
=E2=9C=89 Regards :: Kri= shna Pavan =E2=9C=8D

--bcaec5396c60d1ec6604c0b1fff4-- --===============9109661375601623983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============9109661375601623983==-- From xen-arm-bounces@lists.xen.org Fri May 25 20:53:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 May 2012 20:53: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 1SY1VS-0000Op-Lv; Fri, 25 May 2012 20: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 1SY1F4-0007of-HU for xen-arm@lists.xen.org; Fri, 25 May 2012 20:36:10 +0000 Received: from [85.158.143.35:54595] by server-1.bemta-4.messagelabs.com id D3/0D-00342-93DEFBF4; Fri, 25 May 2012 20:36:09 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1337978166!14137293!1 X-Originating-IP: [209.85.160.173] 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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28147 invoked from network); 25 May 2012 20:36:08 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 25 May 2012 20:36:08 -0000 Received: by ghrr14 with SMTP id r14so813669ghr.32 for ; Fri, 25 May 2012 13:36:06 -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=u4Cw2IxkDDCWrl1l9XkUGGrB2UpXcZkaQzwE80CA45s=; b=zW92w04JZOssSWYKF6BWgz05111YM10Qzwp8B/pN2iBv+aDuTlQa9epZurgTs3K9MC WSS/I6UOpkI2ADHWXT/Ll0FIg2P6UipFM/Mv/6HGdvnQY6jhA02hU+ejHP3IOV/VOMmj 4F6LT4XwB2EsOebUPiWyp4qfJqQpjjyFI9iMPRRSdqo5TCsY1lA2zokPKlGhLmeG+nY+ aUEmM/Hn2+BLxcavJt7boupQhaTi/HilRY1hxl5nLTZorSmB8Xrd8NVDnKXoLykrB3lg RTJ6OszC7iG77RQH/xHlG0K80O3Us6OLzhgBtsjYRSq49dqIXO2TG61jovAJ22Bc1VlS U6dA== MIME-Version: 1.0 Received: by 10.50.156.197 with SMTP id wg5mr125153igb.31.1337978165968; Fri, 25 May 2012 13:36:05 -0700 (PDT) Received: by 10.231.46.10 with HTTP; Fri, 25 May 2012 13:36:05 -0700 (PDT) Date: Fri, 25 May 2012 21:36:05 +0100 Message-ID: From: Lars Kurth To: xen-api@lists.xen.org, xen-devel@lists.xen.org, xen-arm@lists.xen.org X-Mailman-Approved-At: Fri, 25 May 2012 20:53:05 +0000 Subject: [XenARM] Xen Document Day: May 28th X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9145084629571053153==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============9145084629571053153== Content-Type: multipart/alternative; boundary=e89a8f3ba95f4cbe2c04c0e251ea --e89a8f3ba95f4cbe2c04c0e251ea Content-Type: text/plain; charset=ISO-8859-1 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. 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! --e89a8f3ba95f4cbe2c04c0e251ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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_Doc= ument_Days

Hope to see you on IRC! Feel free to add stuff to the TODO list (http://wiki.xen.org/wi= ki/Xen_Document_Days/TODO) or put your name besides an item if you intend to work on it.

Best Regards
Lars

*********************
* Xen Document Days *
*********************

We have another Xen document day come up next Monday. Xen Document Days are for people who care a= bout 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?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Join us on IRC: freenode channel #xendocs
- Tell people what you intend to work on (to avoid doing something somebody
=A0 else is already working on)
- Fix some documentation
- Help others
- And above all: have fun!
--e89a8f3ba95f4cbe2c04c0e251ea-- --===============9145084629571053153== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============9145084629571053153==-- From xen-arm-bounces@lists.xen.org Fri May 25 20:53:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 May 2012 20:53: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 1SY1VS-0000Op-Lv; Fri, 25 May 2012 20: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 1SY1F4-0007of-HU for xen-arm@lists.xen.org; Fri, 25 May 2012 20:36:10 +0000 Received: from [85.158.143.35:54595] by server-1.bemta-4.messagelabs.com id D3/0D-00342-93DEFBF4; Fri, 25 May 2012 20:36:09 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1337978166!14137293!1 X-Originating-IP: [209.85.160.173] 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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28147 invoked from network); 25 May 2012 20:36:08 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 25 May 2012 20:36:08 -0000 Received: by ghrr14 with SMTP id r14so813669ghr.32 for ; Fri, 25 May 2012 13:36:06 -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=u4Cw2IxkDDCWrl1l9XkUGGrB2UpXcZkaQzwE80CA45s=; b=zW92w04JZOssSWYKF6BWgz05111YM10Qzwp8B/pN2iBv+aDuTlQa9epZurgTs3K9MC WSS/I6UOpkI2ADHWXT/Ll0FIg2P6UipFM/Mv/6HGdvnQY6jhA02hU+ejHP3IOV/VOMmj 4F6LT4XwB2EsOebUPiWyp4qfJqQpjjyFI9iMPRRSdqo5TCsY1lA2zokPKlGhLmeG+nY+ aUEmM/Hn2+BLxcavJt7boupQhaTi/HilRY1hxl5nLTZorSmB8Xrd8NVDnKXoLykrB3lg RTJ6OszC7iG77RQH/xHlG0K80O3Us6OLzhgBtsjYRSq49dqIXO2TG61jovAJ22Bc1VlS U6dA== MIME-Version: 1.0 Received: by 10.50.156.197 with SMTP id wg5mr125153igb.31.1337978165968; Fri, 25 May 2012 13:36:05 -0700 (PDT) Received: by 10.231.46.10 with HTTP; Fri, 25 May 2012 13:36:05 -0700 (PDT) Date: Fri, 25 May 2012 21:36:05 +0100 Message-ID: From: Lars Kurth To: xen-api@lists.xen.org, xen-devel@lists.xen.org, xen-arm@lists.xen.org X-Mailman-Approved-At: Fri, 25 May 2012 20:53:05 +0000 Subject: [XenARM] Xen Document Day: May 28th X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9145084629571053153==" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org --===============9145084629571053153== Content-Type: multipart/alternative; boundary=e89a8f3ba95f4cbe2c04c0e251ea --e89a8f3ba95f4cbe2c04c0e251ea Content-Type: text/plain; charset=ISO-8859-1 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. 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! --e89a8f3ba95f4cbe2c04c0e251ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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_Doc= ument_Days

Hope to see you on IRC! Feel free to add stuff to the TODO list (http://wiki.xen.org/wi= ki/Xen_Document_Days/TODO) or put your name besides an item if you intend to work on it.

Best Regards
Lars

*********************
* Xen Document Days *
*********************

We have another Xen document day come up next Monday. Xen Document Days are for people who care a= bout 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?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Join us on IRC: freenode channel #xendocs
- Tell people what you intend to work on (to avoid doing something somebody
=A0 else is already working on)
- Fix some documentation
- Help others
- And above all: have fun!
--e89a8f3ba95f4cbe2c04c0e251ea-- --===============9145084629571053153== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm --===============9145084629571053153==-- From xen-arm-bounces@lists.xen.org Mon May 28 02:15:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 28 May 2012 02:15: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 1SYpU3-0005Vr-Nj; Mon, 28 May 2012 02:14:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SYpU2-0005Vm-F9 for xen-arm@lists.xen.org; Mon, 28 May 2012 02:14:58 +0000 Received: from [193.109.254.147:61650] by server-11.bemta-14.messagelabs.com id 56/84-05858-1AFD2CF4; Mon, 28 May 2012 02:14:57 +0000 X-Env-Sender: zhuanchen@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1338171297!10819617!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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28151 invoked from network); 28 May 2012 02:14:57 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 May 2012 02:14:57 -0000 Received: by werf3 with SMTP id f3so2128694wer.32 for ; Sun, 27 May 2012 19:14:56 -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 :content-transfer-encoding; bh=mr6aSkTR8AfHqXzD0eatscHvoxxRuff1ut6w850aOxE=; b=JyRtO19hBAMy+exNJFXCqrWTqN6CM98RaYM8bg6aKYk65VGTkleLdtaOOweKyRg509 VDffqBv+arCGZbVQBZW3TeZbnvZpAgEyRM1tKZyj2OmLtr+2MRso7nXNzIBPbSHVF8go rM27uH1fMO/kd7OuLcgU7s2WrHy09bXwW4IGAxlKwK7+1KoV02yRcunFI/gkWEpkUGdl HfMhq7I3d28Kz7dXZjbSPCVrhjjsa3K51ldqm4WwLWChOJ1CgYduNTxbi2HUXoTSEun8 8zFdsD1ldrRtrKupTxrxNzQXZ25QWDGiACeQpBuiwGtoM5Of0KPRrpr6iTWGlWZ/wAWv xbVg== Received: by 10.180.83.197 with SMTP id s5mr11895080wiy.9.1338171296850; Sun, 27 May 2012 19:14:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.170.194 with HTTP; Sun, 27 May 2012 19:14:36 -0700 (PDT) From: Zhuan Chen Date: Sun, 27 May 2012 22:14:36 -0400 Message-ID: To: xen-arm@lists.xen.org Subject: [XenARM] Questions about deploying Xen ARM on Tegra 3 board X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Hi All, Recently I am playing with the new Nvidia Tegra 3 developer kit and hope to deploy the Xen ARM on it. The version I am looking at is downloaded from git://xenbits.xen.org/people/jm77ryu/xen-unstable-arm.git. It looks a little different from the way of deploying Xen on x86 machines and I have some questions about it: 1. Does Xen ARM supports VM migration and dynamic memory management? (According to the document of Secure_Xen_on_ARM_User_Guide_v1_1.pdf, Xen ARM only supports =93static partitioning=94 of system memory. But it's an old doc though). 2. Nvidia released the Linux for Tegra (L4T) with kernel 3.1.10 and several supports to Tegra. Can I use this kernel as the Dom0 kernel (since kernel 3.0.0 has contained the support to Xen), or I need to use the kernel 2.6.18 checked out from the Xen mercurial repository (does it also work for Xen ARM)? 3. To boot Xen on x86 machines, the GRUB will put the xen.gz as the kernel and the Dom0 kernel as the module. Here, for Xen ARM, if we use the xen.gz as the kernel image, then how do we deal with the Dom0 kernel image (vmlinux) (suppose using u-boot)? Can anyone with experience give me some help and suggestion? Thank you very much. Regards, -Zhuan _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Mon May 28 02:15:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 28 May 2012 02:15: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 1SYpU3-0005Vr-Nj; Mon, 28 May 2012 02:14:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SYpU2-0005Vm-F9 for xen-arm@lists.xen.org; Mon, 28 May 2012 02:14:58 +0000 Received: from [193.109.254.147:61650] by server-11.bemta-14.messagelabs.com id 56/84-05858-1AFD2CF4; Mon, 28 May 2012 02:14:57 +0000 X-Env-Sender: zhuanchen@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1338171297!10819617!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-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28151 invoked from network); 28 May 2012 02:14:57 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 May 2012 02:14:57 -0000 Received: by werf3 with SMTP id f3so2128694wer.32 for ; Sun, 27 May 2012 19:14:56 -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 :content-transfer-encoding; bh=mr6aSkTR8AfHqXzD0eatscHvoxxRuff1ut6w850aOxE=; b=JyRtO19hBAMy+exNJFXCqrWTqN6CM98RaYM8bg6aKYk65VGTkleLdtaOOweKyRg509 VDffqBv+arCGZbVQBZW3TeZbnvZpAgEyRM1tKZyj2OmLtr+2MRso7nXNzIBPbSHVF8go rM27uH1fMO/kd7OuLcgU7s2WrHy09bXwW4IGAxlKwK7+1KoV02yRcunFI/gkWEpkUGdl HfMhq7I3d28Kz7dXZjbSPCVrhjjsa3K51ldqm4WwLWChOJ1CgYduNTxbi2HUXoTSEun8 8zFdsD1ldrRtrKupTxrxNzQXZ25QWDGiACeQpBuiwGtoM5Of0KPRrpr6iTWGlWZ/wAWv xbVg== Received: by 10.180.83.197 with SMTP id s5mr11895080wiy.9.1338171296850; Sun, 27 May 2012 19:14:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.170.194 with HTTP; Sun, 27 May 2012 19:14:36 -0700 (PDT) From: Zhuan Chen Date: Sun, 27 May 2012 22:14:36 -0400 Message-ID: To: xen-arm@lists.xen.org Subject: [XenARM] Questions about deploying Xen ARM on Tegra 3 board X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Hi All, Recently I am playing with the new Nvidia Tegra 3 developer kit and hope to deploy the Xen ARM on it. The version I am looking at is downloaded from git://xenbits.xen.org/people/jm77ryu/xen-unstable-arm.git. It looks a little different from the way of deploying Xen on x86 machines and I have some questions about it: 1. Does Xen ARM supports VM migration and dynamic memory management? (According to the document of Secure_Xen_on_ARM_User_Guide_v1_1.pdf, Xen ARM only supports =93static partitioning=94 of system memory. But it's an old doc though). 2. Nvidia released the Linux for Tegra (L4T) with kernel 3.1.10 and several supports to Tegra. Can I use this kernel as the Dom0 kernel (since kernel 3.0.0 has contained the support to Xen), or I need to use the kernel 2.6.18 checked out from the Xen mercurial repository (does it also work for Xen ARM)? 3. To boot Xen on x86 machines, the GRUB will put the xen.gz as the kernel and the Dom0 kernel as the module. Here, for Xen ARM, if we use the xen.gz as the kernel image, then how do we deal with the Dom0 kernel image (vmlinux) (suppose using u-boot)? Can anyone with experience give me some help and suggestion? Thank you very much. Regards, -Zhuan _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Mon May 28 07:49:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 28 May 2012 07:49: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 1SYuhm-0008HD-NR; Mon, 28 May 2012 07:49:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SYuhl-0008Gt-Cl for xen-arm@lists.xen.org; Mon, 28 May 2012 07:49:29 +0000 Received: from [85.158.138.51:24323] by server-5.bemta-3.messagelabs.com id 52/DE-25552-70E23CF4; Mon, 28 May 2012 07:49:27 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1338191367!21349434!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22298 invoked from network); 28 May 2012 07:49:27 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 May 2012 07:49:27 -0000 Received: by eekd41 with SMTP id d41so664326eek.32 for ; Mon, 28 May 2012 00:49:26 -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=2KegckbCtQAFLO9RkLjsoymrS19MbANfyy856iQreis=; b=McV8UtIF8xoxB+lXHCuoPSbN6h5Rr2gwk+Jg9Ke0an65KaeeI9Cw914SiY7smxZ99w 7h01OaoHKMTmesNhiIowQ8FeW9uKYx/TDXdhMcHXCU8LVaZPSvd9QZk8lAXXdNrLzYbK hhdiEAcu/8txP7ObI+kFK6eoOaiO3jra/Jy2hER7OYlPIONOGPtDCvJAysFoqu++9yAL MCgIPldho/OdXs2GcLnhJOIeoGrOmwwNl4mV9Pt4KFyi/ZGvdAXLqJipjaV3mPHg4W4p EYB0JRA+6d3hjPaiANtaz5znRRW0EckLHa9QVAbiEg6PIYmOvN67x6SJncN42RUG2VnI FdsQ== Received: by 10.14.119.142 with SMTP id n14mr1438135eeh.20.1338191366764; Mon, 28 May 2012 00:49:26 -0700 (PDT) Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233]) by mx.google.com with ESMTPS id u10sm34175731eem.1.2012.05.28.00.49.24 (version=SSLv3 cipher=OTHER); Mon, 28 May 2012 00:49:25 -0700 (PDT) Message-ID: <4FC32E03.7030102@xen.org> Date: Mon, 28 May 2012 08:49:23 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen-devel@lists.xen.org, xen-arm@lists.xen.org, "xen-api@lists.xen.org" Subject: [XenARM] Quick reminder X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Just to let you know that Xen Document Day is on #xendocs _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Mon May 28 07:49:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 28 May 2012 07:49: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 1SYuhm-0008HD-NR; Mon, 28 May 2012 07:49:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SYuhl-0008Gt-Cl for xen-arm@lists.xen.org; Mon, 28 May 2012 07:49:29 +0000 Received: from [85.158.138.51:24323] by server-5.bemta-3.messagelabs.com id 52/DE-25552-70E23CF4; Mon, 28 May 2012 07:49:27 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1338191367!21349434!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22298 invoked from network); 28 May 2012 07:49:27 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 May 2012 07:49:27 -0000 Received: by eekd41 with SMTP id d41so664326eek.32 for ; Mon, 28 May 2012 00:49:26 -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=2KegckbCtQAFLO9RkLjsoymrS19MbANfyy856iQreis=; b=McV8UtIF8xoxB+lXHCuoPSbN6h5Rr2gwk+Jg9Ke0an65KaeeI9Cw914SiY7smxZ99w 7h01OaoHKMTmesNhiIowQ8FeW9uKYx/TDXdhMcHXCU8LVaZPSvd9QZk8lAXXdNrLzYbK hhdiEAcu/8txP7ObI+kFK6eoOaiO3jra/Jy2hER7OYlPIONOGPtDCvJAysFoqu++9yAL MCgIPldho/OdXs2GcLnhJOIeoGrOmwwNl4mV9Pt4KFyi/ZGvdAXLqJipjaV3mPHg4W4p EYB0JRA+6d3hjPaiANtaz5znRRW0EckLHa9QVAbiEg6PIYmOvN67x6SJncN42RUG2VnI FdsQ== Received: by 10.14.119.142 with SMTP id n14mr1438135eeh.20.1338191366764; Mon, 28 May 2012 00:49:26 -0700 (PDT) Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233]) by mx.google.com with ESMTPS id u10sm34175731eem.1.2012.05.28.00.49.24 (version=SSLv3 cipher=OTHER); Mon, 28 May 2012 00:49:25 -0700 (PDT) Message-ID: <4FC32E03.7030102@xen.org> Date: Mon, 28 May 2012 08:49:23 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen-devel@lists.xen.org, xen-arm@lists.xen.org, "xen-api@lists.xen.org" Subject: [XenARM] Quick reminder X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org Just to let you know that Xen Document Day is on #xendocs _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Mon May 28 08:09:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 28 May 2012 08:09: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 1SYv0Y-0000em-RO; Mon, 28 May 2012 08:08:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SYv0X-0000eN-El for xen-arm@lists.xen.org; Mon, 28 May 2012 08:08:53 +0000 Received: from [85.158.139.83:55696] by server-10.bemta-5.messagelabs.com id 38/16-22179-49233CF4; Mon, 28 May 2012 08:08:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1338192530!30667386!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5OTk1Nw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13779 invoked from network); 28 May 2012 08:08:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 May 2012 08:08:50 -0000 X-IronPort-AV: E=Sophos;i="4.75,669,1330905600"; d="scan'208";a="12690120" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 May 2012 08:08: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.213.0; Mon, 28 May 2012 09:08:27 +0100 Message-ID: <1338192505.14158.6.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "lars.kurth@xen.org" Date: Mon, 28 May 2012 09:08:25 +0100 In-Reply-To: <4FC32E03.7030102@xen.org> References: <4FC32E03.7030102@xen.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-arm@lists.xen.org" , "xen-api@lists.xen.org" , "xen-devel@lists.xen.org" Subject: Re: [XenARM] Quick reminder X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Mon, 2012-05-28 at 08:49 +0100, Lars Kurth wrote: > Just to let you know that Xen Document Day is on #xendocs Heads up: this isn't the same channel as previous docs days ... Ian. _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm From xen-arm-bounces@lists.xen.org Mon May 28 08:09:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 28 May 2012 08:09: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 1SYv0Y-0000em-RO; Mon, 28 May 2012 08:08:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SYv0X-0000eN-El for xen-arm@lists.xen.org; Mon, 28 May 2012 08:08:53 +0000 Received: from [85.158.139.83:55696] by server-10.bemta-5.messagelabs.com id 38/16-22179-49233CF4; Mon, 28 May 2012 08:08:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1338192530!30667386!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5OTk1Nw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13779 invoked from network); 28 May 2012 08:08:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 May 2012 08:08:50 -0000 X-IronPort-AV: E=Sophos;i="4.75,669,1330905600"; d="scan'208";a="12690120" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 May 2012 08:08: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.213.0; Mon, 28 May 2012 09:08:27 +0100 Message-ID: <1338192505.14158.6.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "lars.kurth@xen.org" Date: Mon, 28 May 2012 09:08:25 +0100 In-Reply-To: <4FC32E03.7030102@xen.org> References: <4FC32E03.7030102@xen.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-arm@lists.xen.org" , "xen-api@lists.xen.org" , "xen-devel@lists.xen.org" Subject: Re: [XenARM] Quick reminder X-BeenThere: xen-arm@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List for Xen ARM developers and users List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-arm-bounces@lists.xen.org Errors-To: xen-arm-bounces@lists.xen.org On Mon, 2012-05-28 at 08:49 +0100, Lars Kurth wrote: > Just to let you know that Xen Document Day is on #xendocs Heads up: this isn't the same channel as previous docs days ... Ian. _______________________________________________ Xen-arm mailing list Xen-arm@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

=C2=A0		=20 =C2=A0Seehwan Yoo =20 =20 =C2=A0=C2=A0Ph. D. candidate =20 =20 =C2=A0T=C2=A0+ 82-2-3290-3639 =20 =20 =C2=A0F=C2=A0+ 82-2-922-6341 =20 =20 =C2=A0E=C2=A0shyoo@os.korea.ac.kr =20 =C2=A0
=20 = Home Page=C2=A0\|=C2=A0=20 Blog=C2=A0\|=C2=A0=20 OSVirtual=20

=C2=A0	=C2=A0OSLab.=C2=A0=E2=80=A2=20 Korea Univ. =E2=80=A2=20 Seoul=C2=A0=C2=A0=E2=80=A2= =20 South Korea=20

		=20 Seehwan Yoo =20 =20 Ph. D. candidate =20 =20 T + = 82-2-3290-3639 =20 =20 F + = 82-2-922-6341 =20 =20 E shyoo@os.korea.ac.kr =20
=20 Home Page \| =20 Blog \| =20 OSVirtual=20

	OSLab. =E2=80=A2=20= Korea Univ. =E2=80=A2=20 Seoul =E2=80=A2=20 South Korea=20